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ABSTRACT 


Department  of  Defense  Standard  2167A  mandates  that 
requirements  traceed>ility  be  conducted  during  the 
development  of  government  systems.  This  and  other 
standards,  as  well  as  current  literature,  however,  do  not 
provide  a  comprehensive  model  of  what  information  should  be 
captured  as  a  part  of  a  traceediility  scheme. 

The  primary  goal  of  this  research  is  to  develop  a  model 
of  requirements  traceability  at  the  level  of  systems  design 
which  relates  requirements  to  all  system  components.  An 
empirical  study  using  focus  groups  was  conducted  with 
various  stakeholders  involved  with  the  development  of  large, 
complex  systems.  Based  on  an  analysis  of  the  information 
obtained  by  the  focus  group  sessions,  a  model  for 
traceability  was  developed.  This  model  describes  the 
various  relationships  or  linkages  between  requirements  and 
system  components  that  must  be  captured  and  maintained  to 
support  various  system  development  activities.  Finally, 
several  issues  which  must  be  addressed  in  successfully 
implementing  a  comprehensive  scheme  for  traceeO^ility  are 
discussed. 
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I .  IHTRODUCTIOa 


A.  THESIS  OBJECTIVES 

The  goal  of  this  thesis  is  to  develop  a  model  for 
requirements  traceability  at  the  level  of  systems  design 
which  relates  requirements  to  all  system  components.  This 
model  should  provide  the  semantics  of  the  various 
traceability  linkages  or  relationships  between  requirements 
and  various  system  components.  It  should  also  identify 
mechanisms  for  reasoning  with  traceability  information  to 
support  systems  development  and  maintenance  activities.  A 
secondary  objective  is  to  understand  the  critical  issues 
that  relate  to  the  capture  and  use  of  traceability 
information  in  systems  development. 

A  basic  premise  in  the  current  research,  the  results  of 
which  are  contained  in  this  document,  is  that  development  of 
a  model  of  traceability  could  be  geared  toward  the  needs  of 
stakeholders  at  various  stages  of  the  systems  development 
process.  A  variety  of  stakeholders  are  involved  in  the 
systems  development  process,  including  project  sponsors, 
project  managers,  analysts,  designers,  maintainers,  testing 
personnel,  and  end  users.  An  empirical  approach  is  used  in 
this  research  to  identify  stakeholders'  needs.  Our  study 
explores  the  information  needs  of  various  stakeholders. 


Based  on  these  stakeholder  needs,  we  propose  a 
conceptual  model  of  requirements  traceed:>ility .  We  also 
identify  the  critical  issues  to  be  addressed  by  various 
stakeholders  when  implementing  a  comprehensive  scheme  for 
requirements  traceedsility.  This  study  was  conducted  with 
real  stakeholders  in  large  scale,  complex,  real-time  systems 
development  efforts. 

Given  the  above  objectives,  the  following  questions  are 
addressed: 

•  What  information  should  stakeholders  capture  as  a  part 
of  requirements  traceability? 

•  During  what  phases  of  systems  development  is  this 
information  captured,  which  stakeholders  capture  it, 
and  then  who  maintains  this  information? 

•  How  is  this  information  used  to  relate  requirements  to 
systems  components? 

•  What  are  the  critical  issues  in  implementing  a  scheme 
of  requirements  traceability  which  supports  various 
stakeholders  in  systems  development? 

B.  METHODOLOGIES 

A  thorough  literature  review  of  requirements 
traceability,  was  conducted  to  understand  the  state-of-the- 
art  and  current  methodologies  for  requirements  traceedsility. 
Prior  to  conducting  focus  group  interviews,  the  authors 
attended  a  course  on  using  focus  group  methodology  for  data 
collection. 

Focus  group  interviews  served  as  the  means  of  data 
collection  for  this  research.  The  focus  group  interview  is 
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recognized  as  a  valid  and  consistent  qualitative  marketing 
technique.  Focus  groups  are  highly  flexible  and  appropriate 
for  generating  ideas,  producing  information,  measuring 
potential  problems,  and  encouraging  creativity.  A  focus 
group  is  not  a  rigidly  constructed  question  and  answer 
session.  It  is  a  semi-structured  exchange  eunong  group 
members  which  follows  a  clear  agenda. 

In  this  research,  a  total  of  45  subjects  in  seven  focus 
groups,  with  5  to  8  participants  each,  discussed  information 
requirements  of  stakeholders  for  requirements  traceeUsility. 
The  groups  were  under  the  direction  of  a  moderator  (one  of 
the  authors  of  this  thesis)  who  promoted  discussion  and 
ensured  that  the  group  stayed  on  the  subject.  Each  focus 
group  interview  was  between  one  and  one  half  to  two  hours  in 
length. 

Focus  groups  were  conducted  at  International  Business 
Machines  (IBM),  Federal  Systems  Division,  Owego,  NY; 

National  Aeronautics  and  Space  Administration  (NASA) 

Langley,  Hampton  Roads,  VA;  Naval  Surface  Warfare  Center 
Dahlgren  Division,  Dahlgren,  VA;  Naval  Surface  Warfare 
Center  Port  Hueneme  Division,  Ventura,  CA;  and  Naval 
Undersea  Warfare  Center,  New  London,  CT.  These 
organizations  procure  and  manage  the  development  of 
aerospace,  communications,  weapons,  and  aircraft  systems,  as 
well  as  perform  systems  integration. 
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The  participants  represented  many  levels  of  expertise 
and  job  responsibilities.  The  average  years  of  education 
(after  receiving  a  high  school  diploma)  was  5.5  years, 
representing  the  following  degrees:  PhD,  MBA,  MS,  MA,  BS, 

BA.  These  degrees  were  from  various  academic  areas: 
Electrical  Engineering,  Aerospace  Engineering,  Computer 
Engineering,  Mechanical  Engineering,  Systems  Engineering, 
Software  Engineering,  Physics,  Geophysics,  and  Mathematics. 
Further,  the  participants  represented  an  average  of  17  years 
work  experience  in  systems  development.  The  participants 
were  involved  in  systems  development  ranging  from  several 
hundred  thousand  lines  of  code  to  over  several  million. 

Projects  worked  on  by  the  participants  included: 
Networking  Technology,  Aegis  Reengineering  Effort,  Tomahawk 
Weapons  System  Analysis  Tools,  Hiper-D,  Cassandra  Data 
Analysis/  Reduction,  Next  Generation  Computer  Resources, 
Standard  Missile,  TARTAR,  FFG-7  MK  92,  Space  Station 
Freedom,  F-16,  A-12,  Real  time  Embedded  Software  Science 
Applications,  New  Attack  Submarine,  AN/BSY-2,  EASE 
(Efficient  Approach  to  Systems  Evolution),  Snecial  Warfare 
Analysis  and  Engineering,  integrated  Process  Working  Group, 
Navy  Leunps  MK-III,  Combat  Talon  II,  Block  II  Upgrade,  and 
SBIS  (Sustaining  Base  Information  Services-Army ) . 
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C.  SCOPE  AMO  LIMITATIONS  OP  THE  STUDY 

Not  all  of  the  focus  group  participants  were  familiar 
with  current  traceability  tools  and  techniques,  but  all  had 
sufficient  interest  in  the  topic  to  actively  contribute  to 
the  discussions.  This  research  is  designed  to  identify  the 
information  needs  of  the  various  stakeholders  throughout  the 
systems  development  process.  Further,  this  research 
examines  how  captured  information  is  maintained  and  used 
throughout  the  systems  development  process.  Analysis  of 
data  from  focus  groups  is  used  to  develop  a  model  for 
requirements  traceability.  It  should  be  noted  that  this 
research  is  not  designed  to  evaluate  or  compare  current 
traceeUaility  tools  nor  is  its  purpose  to  develop  a  tool  to 
support  traceability. 

0.  ORGANIZATION  OP  THESIS 

Chapter  II  provides  a  literature  review  on  the  general 
topic  of  traceedaility.  This  includes  a  definition  of 
requirements  traceability,  its  goals  and  objectives,  why  and 
how  traceability  is  used,  and  the  role  of  traceeibility  in 
DoD/DoN.  This  chapter  also  conducts  a  brief  presentation  of 
some  tools  currently  availedsle  that  support  requirements 
traceability. 

Chapter  III  is  based  on  an  analysis  of  data  collected 
from  the  focus  groups.  A  model  for  requirements 
traceedjility  is  presented,  concentrating  on  the  semantics  of 


linkages  as  identified  by  the  focus  group  participants. 

This  model  focuses  on  capturing  the  information  needs  of 
stakeholders. 

Chapter  IV  describes  the  critical  issues  in  implementing 
requirements  traceability  as  discussed  by  the  focus  group 
participants.  These  issues  must  be  resolved  if  a 
comprehensive  scheme  of  traceability  is  to  be  successful. 

The  final  chapter  draws  conclusions  based  on  resenrch 
data,  and  makes  specific  recommendations  resulting  from  the 
research  effort.  This  chapter  concludes  with  recommended 
areas  for  additional  research. 

E .  ACKN0HLED6EMEIIT 

The  authors  would  like  to  thank  the  participants  of  the 
focus  group  interviews.  Special  thanks  to  Dr.  Donne  Rhodes 
of  IBM,  Dr.  Susan  Voight  of  NASA,  Mr.  Rick  Stuttler  of  NSWC 
DD,  Mr.  Chuck  Hogle  of  NSWC  PHD,  and  Mr.  Tom  Choinski  of 
NUWC.  We  are  very  grateful  for  all  of  their  assistance  in 
arranging  participation  in  the  focus  groups  and  for 
providing  logistics  support  during  our  research. 
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II.  LITERATURE  REVIEW 


A  prinaxy  concern  in  the  development  of  complex,  large- 
scale,  real-time,  computer- intensive  systems  is  ensuring 
that  the  design  of  the  system  meets  the  specified 
requirements.  As  part  of  the  systems  development  and 
maintenance  process,  many  decisions  and  tradeoffs  are  made 
that  affect  a  variety  of  system  components.  The 
requirements  are  subject  to  change  and  often  evolve  during 
the  development  process. 

Due  to  the  size  and  complexity  of  these  systems,  the 
entire  systems  development  process  has  become  quite 
challenging  to  manage.  Funding,  time,  and  personnel  are 
often  at  a  premium,  as  well  as  technological  resources. 
Advancements  in  computer  technology  encourage  increased 
tasking  of  systems  designers. 

In  such  a  context,  it  is  essential  to  maintain  the 
traceadsility  of  requirements  to  various  outputs  produced 
during  the  system's  design  process,  ensuring  that  the  system 
meets  the  stated  requirements  and  stays  within  established 
resource  parameters.  It  is  also  necessary  to  acquire  a 
greater  knowledge  of  the  concepts  of  traceed^ility.  The 
following  is  a  brief  review  of  literature  focusing  on 
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requirements  traceability — how  DoD  and  DoH  view  it,  what  is 
it,  and  methods  and  models  of  traceability,  and  some  tools 
that  use  it. 

A.  TRACBABZLITT  IM  000  AVO  OON 

As  one  of  the  world's  major  users  of  large-scale, 
computer-based  systems,  DoD  takes  a  detailed  approach  to  the 
dilemma  of  specifying  systems  requirements  through  the  use 
of  military  standards.  "Traceability  is  a  key  driver  in 
defining  and  developing  software  under  DoD-STD-2167A" 
(Walters,  1991,  p.  174). 

In  February  1988,  DoD  specified  its  requirements  for 
systems  development  in  its  DoD  Standard,  Defense  System 
Software  Development,  DoD-STD-2167A.  "Government  software 
development  standards  in  general,  and  DoD-STD-2167A  in 
particular,  are  only  required  for  military  software  which  is 
mission  critical"  (Roetzheim,  1991,  p.  12).  In  general, 
however,  all  projects  for  the  military  normally  require  that 
the  standards  are  complied  with.  Further,  nonmilitary 
government  software  for  which  reliability  is  a  significant 
concern  is  typically  done  in  compliance  with  these 
standards.  "Most  large  defense  contractors  require  the  use 
of  DOD-STD-2167A  for  all  software  development,  including 
software  developed  using  internal  research  and  development 
funds"  (Roetzheim,  1991,  p.  13). 
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This  DoD  standard  mandates  that  requirements  be 
traceable  through  the  entire  system.  Traceability,  as  used 
in  this  standard,  means  that  "the  dociunent  in  question  is  in 
agreement  with  a  predecessor  document  to  which  it  has  a 
hierarchical  relationship."  (DoD-STD’>2167A,  10.2.3)  DoD- 
STD-2167A  formalizes  the  tracing  of  requirements  (in 
documents)  "from  the  initial  set  provided  by  the  customer, 
to  the  contractor-written  detailed  requirements 
specifications,  to  the  software  and  hardware  design,  and  to 
the  test  procedures  and  results"  (Walters,  1991,  p.  174). 

DoD-STD-2167A  specifically  requires  the  traceed^ility  of 
requirements  to  design.  In  accordance  with  this  standard, 
the  contractor  must  document  the  traceability  of  the 
requirements  allocated  from  the  system  specification  to  each 
Computer  Software  Configuration  Item  (CSCI),  its  Computer 
Software  Components  (CSCs)  and  Computer  Software  Units 
(CSUs),  and  from  the  CSU  level  to  the  Software  Requirements 
Specifications  (SRSs)  and  Interface  Requirements 
Specification  (IRS).  Additionally,  this  standard  requires 
traceability  of  requirements  to  test  cases.  For  this,  the 
contractor  shall  document  the  traceability  of  the 
requirements  in  the  SRSs  and  IRSs  that  are  satisfied  or 
partially  satisfied  by  each  test  case  identified  in  the 
Software  Test  Description  (STD).  "The  contractor  shall 
document  this  traceability  in  the  STD  for  each  CSCI."  (DoD- 
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STD-2167A/  4.3.4)  Finally,  "the  contractor  shall  document 
and  implement  plans  for  performing  configuration  status 
accounting"  (DoD-STD-2167A,  4.5.3).  This  requires  that  the 
contractor  generate  management  records  and  status  reports  on 
all  products  comprising  the  Developmental  Configuration  and 
the  Allocated  and  Product  Baselines.  The  status  report 
shall,  among  several  demands,  "provide  traceed>ility  of 
changes  to  controlled  products"  (DoD-STD>2167A,  4.5.3). 

TraceeUsility,  as  referred  to  in  DoD-STD-2167A,  has  five 
elements: 

•  the  document  in  question  contains  or  implements  all 
applicable  stipulations  of  the  predecessor  document. 

•  a  given  term,  acronym,  or  abbreviation  means  the  same 
thing  in  the  documents. 

•  a  given  item  or  concept  is  referred  to  by  the  same  name 
or  description  in  the  doc\ments. 

•  all  material  in  the  successor  document  has  its  basis  in 
the  predecessor  document,  that  is,  no  untraceable 
material  has  been  introduced. 

•  the  two  documents  do  not  contradict  one  another.  (DoD- 
STD-2167A,  10,2.3) 

By  this  standard  the  government  insists  "that  the 
functional  requirements  which  are  identified  as  part  of  the 
functional  baseline  be  traceeUsle  directly  to  specific 
capabilities  within  the  allocated  baseline,  which  must  then 
be  directly  traceable  to  specific  capabilities  within  the 
product  baseline"  (Roetzheim,  1991,  p.  129).  The  standard 
requires  only  that  "the  mechanism  to  ensure  the  requirements 


10 


are  traceeUsle  throughout  the  process"  (Walters,  1991, 
p.  174)  without  much  eleiboration  on  the  type  of  information 
to  be  maintained  to  achieve  this.  A  clear  definition  of  the 
types  of  information,  or  relationships  between  various 
systems  components  that  are  part  of  a  traceability  scheme, 
is  lacking. 

Having  a  traceability  scheme  that  provides  a  precise 
method  for  ensuring  that  requirements  are  met  by  the  design 
is  vital.  DoD  currently  delineates  its  requirements  to 
contractors  in  documents  that  are  developed  by  numerous 
specialists  in  a  format  that  may  be  thousands  of  pages  long. 

One  of  the  foremost  issues  in  developing  an  efficient 
and  effective  system  involves  the  maintenance  of  consistency 
between  requirements  and  design.  This  consistency  entails 
meeting  the  initial  requirements  and  maintaining 
requirements,  design,  and  implementation  consistently 
throughout  the  entire  systems  lifecycle.  A  key  element 
included  in  a  Request  For  Proposal  (RFP)  must  be 
traceability,  guaranteeing  that  the  current  set  of 
requirements  is  met  by  the  evolving  system  and  the  "tracing 
of  all  system  requirements  to  the  requirements  stated  for 
the  capabilities,  constituents,  and  interfaces."  (Walters, 
1991,  p.  174).  With  declining  defense  dollars,  systems  must 
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be  cost-effective,  and  be  able  to  adapt  to  major  changes 
during  their  lifecycle,  without  losing  contact  with  the 
requirements. 

The  current  method  used  by  the  Navy  to  specify 
requirements  uses  mostly  a  narrative,  English  format  with 
supporting  diagrams  and  charts.  Ambiguities  are  frequent, 
as  English  specifications  are  inexact.  If  specifications 
are  formally  stated  and  can  be  transformed  into  designs  in  a 
formal  manner,  traceability  between  requirements  and  designs 
is  a  by-product  of  the  design  process  itself. 

It  is  commonly  understood  that  changes  to  intricate 
systems  can  result  in  unforeseeedsle  and  disastrous  effects 
to  important  national  defense  systems.  These  problems  could 
be  avoided  if  correct  traceability  methods  are  used  along 
with  proper  maintenance  of  systems. 

B.  TRACEABILITY  EXPLAINED? 

There  is  no  universally  accepted  definition  of 
requirements  traceability,  instead,  there  exists  several 
ideas  in  which  requirements  traceability  is  defined  in  terms 
of  its  function  within  the  system  development  process. 

1 .  Definition 

Hamilton  and  Beeby  (1991)  characterize  traceeUaility 
as  the  "ability  to  discover  the  history  of  every  feature  of 
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a  system"  (Hamilton  and  Beeby,  1991,  p.  1).  They  go  further 
to  say  that  it  is  the  ability  to  determine  what  has  resulted 
from  a  change  request. 

Edwards  and  Howell  offer  a  more  generic  and 
inclusive  definition  of  traceability  as  a  technique  used  to 
"provide  a  relationship  between  the  requirements,  the 
design,  and  the  final  implementation  of  the  system"  (Edwards 
and  Howell,  1991,  p.  3-8).  These  relationships  are  valuable 
to  both  the  designer  and  the  testers  in  that  it  allows 
designers  to  show  that  the  design  meets  the  requirements  and 
that  it  also  allows  for  early  recognition  of  those 
requirements  not  satisfied  by  the  design. 

Greenspan  and  McGowan  (1978)  cite  the  use  of 
traceability  to  effect  changes  in  the  entire  system  at 
various  levels.  Their  definition  of  traceability  looks  at 
the  systems  description  techniques  and  how  they  allow 
changes  to  any  part  of  the  design — requirements, 
specification,  implementation — to  be  traced  throughout  the 
system.  (Greenspan  and  McGowan,  1978,  p.  79) 

2.  Goals  and  Objectives 

The  goal  of  requirements  traceed)ility  is  to  provide 
a  vied)le  technique  for  linking  design  elements  to  the 
requirements  in  a  bi-directional,  complex  manner.  This 
linkage  should  occur  across  all  design  stages  and  design 
views.  (Marconi,  RTM  Product  Overview,  1991,1991)  It  is 
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imperative  that  traceeibility  work  in  both  directions, 
providing  traceability  from  the  requirements  to  the  final 
design  or  output  (forward)  and  from  the  output  back  to  the 
requirements  (backward).  Forward  traceability  allows  one  to 
see  where  requirements  materialize  in  the  finished  system 
whereas  backward  traceability  allows  reference  to  be  made  to 
the  source  of  a  design  element  or  requirement.  Finkelstein 
(1991)  asserts  that  backward  traceedsility  is  much  harder  to 
perform  than  forward.  (Finkelstein,  1991,  p.  l)  in 
requirements  engineering,  for  instance,  the  challenge  is  the 
identification  and  linking  of  various  sources  to  the 
requirements . 

To  effectively  prove  requirements  compliance, 
requirements  traceability  should  also  address  how  the 
requirements  are  arrived  at  as  well  as  the  design  rationale 
that  identifies  not  only  the  decisions,  but  also  the 
supporting/ opposing  reasons  behind  those  decisions  (Ramesh 
and  Edwards,  1993,  p.  257).  In  software  development,  the 
objective  of  requirements  traceed>ility  is  "to  ensure  that 
the  software  produced  meets  the  expectations  of  the  user" 
(Marconi  RTM  Product  Overview,  1991,  p.  1).  In  doing 
tracezd^ility,  software  engineers  will  have  confidence  that 
their  job  has  been  done  to  the  best  of  their  ability  and 
with  the  needs  of  the  customer  as  their  top  priority.  Also, 
the  engineers  will  be  working  to  the  same  goal  from  the  same 
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starting  point.  "(This)  will  result  in  a  product  that  meets 
the  customer  needs... the  customer  is  happy."  (Wright,  1991, 

p.  1) 

Stehle  lists  some  objectives  of  requirements 
traceability  as  to: 

•  promote  a  contractor  and  contracted  method  of  working 

•  demonstrate  that  each  requirement  has  been  satisfied 

•  demonstrate  that  each  component  of  the  system  satisfies 
a  requirement.  (Stehle,  1990,  p.  10) 

A  primary  concern  in  systems  development  is  "ensuring  that 

the  performance  of  the  system  meets  specified  requirements" 

(Ramesh  and  Edwards,  1993,  p.  256).  The  DoD  currently 

delineates  its  requirements  to  contractors  in  documents  that 

are  developed  by  numerous  specialists  in  a  format  that  may 

be  thousands  of  pages  long.  Having  a  precise  method  for 

ensuring  that  requirements  are  met  by  the  design  is  vital; 

therefore,  a  key  element  included  in  a  Request  For  Proposal 

(RFP)  must  be  traceability,  guaranteeing  that  the  current 

set  of  requirements  are  met  by  the  evolving  system.  Because 

of  the  decisions  and  tradeoffs  made  during  systems 

development  and  the  fact  that  requirements  are  dyneunic,  "it 

is  essential  to  maintain  traceability  of  requirements  to 

various  outputs  or  artifacts"  to  ensure  the  system  meets 

stated  requirements  and  that  contractual  obligations  are 

met.  (Ramesh  euid  Edwards,  1993,  p.  256)  Further, 

traceability,  when  included  in  systems  development 
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methodologies,  aims  to  ensure  that  systems  do  only  what  is 
specified  and  no  more  (Stehle,  1990,  p.  7). 

3.  Why  Traceability? 

One  of  the  primary  uses  of  requirements  traceability 
is  for  system  developers  to  prove  to  the  customer  that 
requirements  have  been  understood,  the  product  complies  with 
those  requirements,  and  the  product  has  no  unnecessary 
features  (Wright,  1991,  p.  1).  "Since  the  Navy  typically 
relies  on  contractors  to  design  and  build  large,  complex 
real-time  systems,  having  a  systematic  way  of  validating 
that  every  requirement  is  met  by  the  design  is  important  not 
only  to  ensure  that  the  system  performs  correctly,  but  also 
to  determine  whether  contractual  obligations  have  been  met" 
(Edwards  «uid  Howell,  1992,  p.  2-2). 

Traceability  is  needed  to  ensure  the  closure  of  all 
systems  components.  It  should  alleviate  problems  of 
maintenance  by  identifying  interdependencies  among 
components  and  localizing  the  effects  of  changes  made  at 
various  levels  of  systems  design.  (Ramesh  and  Edwards,  1993, 
p.  256)  Also,  miscommunication  between  the  customer  emd 
systems  engineer  is  a  major  factor  resulting  in  project 
delays,  cost  overruns,  delivery  of  projects  not  meeting 
customer  specifications,  and  project  cancellations. 
Traceability  should  facilitate  communications  between  those 
involved  in  the  project  to  alleviate  some  of  these  problems. 
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Gathinan  and  Halker  (1990)  agree  that  the  edssence  of 
clear  traceetbility  of  design  to  requirements  has  created 
problems  for  project  m2magers,  configuration  control  and  the 
customer.  "Often  the  reason  for  delivery  schedule  slips  is 
mismanagement  of  requirements  traceability"  (Gathman  and 
Halker,  1990). 

Traceability  allows  designers  and  maintainers  to 
keep  track  of  what  happens  when  a  change  request  is 
implemented.  For  example,  during  a  development  project,  if 
a  problem  is  discovered  and  if  traceability  exists  the 
designers  can  determine  the  requirements  incorporating  that 
feature,  the  source  of  those  requirements,  and  "what  checks 
into  the  suitability  and  correctness  of  the  design  were 
performed."  (Hamilton  and  Beeby,  1991,  p.  1^  In  the  same 
manner,  if  a  change  to  the  requirements  is  proposed,  the 
designers  will  be  able  to  ascertain  the  parts  of  the  design 
which  will  be  affected  "by  effectively  relating  each 
requirement  to  a  specific  element  of  the  implementation" 
(Edwards  and  Howell,  1992,  p.  3-8).  This  enables 
implications  of  a  requirements  change  to  be  determined 
before  system  redesign  takes  place.  (Edwards  and  Howell, 
1992,  p.  3-8)  According  to  Finkelstein,  change  is 
consequent  with  systems  evolution  and  requires  a  better 
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understanding  of  the  requirements  •’which  can  only  be 
achieved  by  going  back  to  their  source"  (Finkelsteiu/  1991, 
p.  1) 

Traceability  within  documents  ensures  that  the 
source  "of  the  environment's  contained  information  is 
identifiable"  (Cordes  and  Carver,  1989,  p.l85).  This 
traceability  defines  a  chain  of  account£d5ility  within  the 
development  process.  "All  information  is  linked  directly  to 
its  generating  statements  within  statements  within  the 
original  document"  (Cordes  and  Carver,  1989,  p.  185). 

Additionally,  traceability  enables  engineers  to 
locate  related  requirements  at  higher  and  lower  levels,  that 
must  be  reviewed  to  see  if  changes  are  needed,  "it  refers 
to  the  ability  to  cross-reference  items  in  the  requirements 
specifications  with  items  in  the  design  specifications." 
(Thayer  and  Dorfman,  1990)  With  complete  traceability  more 
accurate  costs  and  schedules  of  changes  can  be  determined 
than  depending  on  the  engineer  or  programmer  to  know  all  the 
areas  effected  by  these  changes.  "Requirements  traceability 
adds  to  what  has  to  be  done  across  the  entire  life  cycle  but 
will  reduce  the  non-productive  work  by  much  more"  (Stehle, 
1990,  p.  26). 

4.  Aspects  of  Traceability 

Requirements  traceability  has  broad  applications 
throughout  the  systems  development  process  that  are  a 


18 


function  of  the  stakeholders  need  and  the  stage  of 
development  in  the  project. 

a.  Keguirements  Management 

Requirements  management  is  "the  process  of 
creating,  disseminating,  maintaining,  and  verifying  product 
requirements  with  regard  to  performance,  cost, 
manufacturability,  maintainability,  and  other  lifecycle 
concerns"  (Fiksel,  1992,  p.  1).  Fiksel  stated  that 
"effective  requirements  management  is  a  key  success  factor 
in  integrated  product  development"  (Fiksel,  1992,  p.  1).  In 
a  survey  of  product  development  managers  that  addressed 
strategies  related  to  the  management  of  technical  and 
business  requirements  for  new  product  development,  the  most 
common  problems  noted  were  the  "lack  of  adequate  precision 
in  requirement  definition,  the  inability  to  communicate 
requirement  changes  in  a  timely  manner  and  product  delays 
due  to  the  late  discovery  of  requirement  conflicts"  (Fiksel, 
1992,  p.  1).  Requirements  traceed^ility  is  essential  for 
requirements  management  as  it  assists  systems  developers 
with  requirements  capture,  tracking  and  verification. 

b.  Design 

Smithers,  Tang  and  Tomes  (1991)  studied  design 
models  that  produced,  among  many  deliverables,  a  design 
history  record  in  which  traceability  of  the  design  process 
is  maintained.  They  state  that  "design  history  reflects  the 


19 


process  of  design  in  the  form  of  a  design  document  in  which 
a  design  result  and  its  justifications  are  clearly  stated” 
(SmitherS/  Tang  and  Tomes,  1991,  p.  1).  Having  design 
history  helps  facilitate  explaining  and  documenting  final 
design  results  as  well  as  repeating  and  restoring 
interrupted  design  sessions  which  become  necessary  on  long 
term  design  projects  where  there  is  a  need  to  review  the 
details  of  previous  design  sessions.  For  design  history  to 
be  meaningful  and  to  support  traceability,  the  following 
should  be  documented: 

•  results  of  the  design 

•  justifications  of  the  results 

•  important  decisions  or  assumptions  made  during  design 

•  contexts  of  the  design  solutions.  (Smithers,  Tang,  and 
Tomes,  1991,  p.  1) 

These  well  documented  design  solutions  and  the  resultant 
justifications  provide  a  "major  source  of  knowledge  for 
maintaining  traceability  throughout  a  design  project  and  for 
evaluating  a  design  project”  (Smithers,  Tang,  and  Tomes, 
1991,  p.  2). 

c.  Testing 

Brown  asserts  that  effective  traceed)ility  can 
also  assist  in  ensuring  that  test  procedures  are  updated 
whenever  errors  are  discovered  which  were  undetected  by  the 
applicable  procedure.  According  to  him,  "test  procedures 
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should  be  traceable  to  the  requirement  or  design  for  which 
they  demonstrate  product  compliance."  (Brown,  1987,  p.9) 

Concerning  the  verification  and  validation 
process,  Marconi  Systems  Technology  declare  that 
"traceability  is  the  only  technique  for  assessment  of 
consistency  between  different  lifecycle  phases  prior  to 
coding"  (Marconi  Systems  Technology,  1991,  p.  17).  They 
further  explain  that  acceptance  testing  is  directly  used  in 
assessing  whether  integrated  systems  meet  the  requirements 
statements.  "Traceability  is  thus  a  major  technique  for 
risk  management  on  a  project."  (Marconi  Systems  Technology, 
1991,  p.  17) 

d.  Maintenance 

Schneidewind  (1982)  describes  traceability  as  a 
mechanism  to  support  maintenance,  focusing  on  the 
maintenance  phase  to  discover  sources  of  error.  He  views 
traceeJsility  as  a  means  of  identifying  technical  information 
that  pertains  to  a  software  error  detected  during  the 
maintenance  phase  and  "thereby  trace  the  error  to  the 
applicedsle  design  specifications  and  user  requirements" 
(Schneidewind,  1982,  p.  4).  Keuffel  states  that  "having  a 
requirements  document  with  traceed>ility  to  data  structure 
and  function  design  will  make  maintenance  far  easier  and  far 
more  accurate"  (Keuffel,  1990,  p.  33). 
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e.  Quality 

Wright  relates  requirements  traceability  to 
quality  as  viewed  by  the  customer.  Quality  "is  the  degree 
of  compliance  to  their  needs  the  product  exhibits."  (Wright, 
1991,  p.2)  What  requirements  traceability  provides  is  a 
"change  in  focus  from  the  product  and  what  it  does  to  what 
the  customers  wants — thus,  ensuring  that  the  product  is  of  a 
high  quality  as  perceived  by  the  customer"  (Wright,  1991, 
p.  2). 

f.  Computer  security 

From  a  computer  security  approach  Murine 
identifies  traceability  as  an  essential  factor  in  the 
establishment  of  data  integrity.  He  further  defines 
security  traceediility,  one  of  the  criteria  for  Software 
Security  Metrics,  as  "those  security  requirements  that 
provide  a  thread  from  the  system  security  requirements  to 
the  implementation  with  respect  to  software  development  and 
security  environment."  (Murine,  1986,  p.  337) 

g.  Reuse 

In  a  reuse  environment,  automated  traceability 
assists  the  user  understanding  of  the  component's  design  and 
implementation  "since  it  captures  the  context  and  the 
constraints  of  the  development  process,"  therefore  assisting 
the  users  of  the  component  in  reusing  it  on  another 
application.  (Baldo,  1990,  pg.  xii) 
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h.  Other  uses 

Other  uses  for  traceability  are  in  "safety 
analysis,  audits,  change  control  and  general  completeness  of 
the  design"  (Hamilton  and  Beeby,  1991,  p.  1).  Brown 
advocates  that  "every  software  product  should  be  traceable 
back  to  the  product  from  which  it  was  derived"  (Brown,  1987, 
p.  9).  With  a  comprehensive  scheme  for  traceability,  "it 
should  be  possible  to  identify  the  requirement  or  design 
decision  from  which  each  algorithm  in  the  software  product 
is  derived"  (Brown,  1987,  p.  9).  Traceability  will  make  it 
easier  for  designers  to  determine  phase  completion  and 
product  completeness.  "It  supports  the  accomplishment  of 
reviews  and  evaluations,  and  provides  for  increased 
confidence  in  the  accuracy  of  requirements  verification." 
(Brown,  1987,  p.  9) 

5.  Who  Benefits  With  Traceability 

A  nximber  of  stakeholders,  each  having  a  different 
set  of  goals  and  priorities,  are  involved  in  the  systems 
development  process,  including  project  sponsors,  project 
managers,  analysts,  designers,  maintainers,  and  end  users. 

Stehle  describes  how  requirements  traceebility  is  of 
value  to  the  end  user  in  the  following  ways: 

•  Providing  an  understanding  of  the  purpose 
behind  each  component  of  the  specification  or 
design 

•  receipt  of  design  documents  specific  to  those 
parts  of  the  system  they  are  responsible  for 
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•  ability  to  determine  that  requirements  are 
satisfied  through  workable  and  acceptable 
solutions.  (Stehle,  1990,  p.  9) 

Stehle  also  lists  the  benefits  of  requirements 

traceability  to  those  stakeholders  who  are  active 

participants  in  the  systems  development  process  as: 


•  ensuring  a  problem  oriented  approach  to  logical  design 
and  physical  implementation 

•  better  estimating  required  resources,  milestone  dates 
and  development  costs  through  greater  understanding  of 
the  factors  involved 

•  providing  additional  focus  for  quality  assurance  of  the 
development  process  and  proposed  system 

•  ability  to  assess  the  impact  of  proposed  changes  to  the 
requirements  because  the  chain  of  system  components 
that  will  be  affected  can  be  traced.  (Stehle,  1990) 

Maintainers  benefit  from  traceability  once  a  change 
is  required.  ”K  maintainer  needs  to  be  able  to  trace  that 
change  back  to  the  requirements  that  necessitated  or 
triggered  it,  and  to  pinpoint  which  parts  of 
design/impleroentation  are  affected  by  the  change."  (Reunesh, 
et  al,  1992) 

C.  METHODS  AND  MODELS  OF  TRACEABILITY 

One  of  the  foremost  issues  in  systems  development 
entails  the  maintenance  of  consistency  between  requirements 
and  design.  Such  consistency  involves  meeting  the  initial 
requirements  and  maintaining  requirements,  design,  and 
implementation  consistently  throughout  the  entire  system 
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lifecycle.  In  the  past,  system  malfunctions  caused  by 
changes  in  the  requirements,  resulted  in  unforeseeedile  and 
sometimes  disastrous  effects.  Some  of  these  projects 
involved  critical  national  defense  systems.  With  proper 
methods  and  models  of  requirements  traceability,  these 
problems  might  have  been  avoided. 

1.  METHODS 

Before  a  model  of  traceability  can  be  developed  it 
is  important  to  first  develop  a  method  for  capturing  and 
using  traceability  information.  Schneidewind  (1982) 
provides  several  formats  for  achieving  traceability.  These 
include:  event  tables  which  relate  modes,  events  emd 
actions;  condition  tables  which  relate  modes,  conditions  and 
actions  or  values;  and,  selector  tables  which  relate  modes 
and  mutually  exclusive  characteristics  of  modes.  These 
tables  provide  a  clear  means  of  identifying  and  capturing 
information  needed  for  traceability. 

Macmillan  and  Vosburgh  (1986),  speaking  on  Software 
Quality  Indicators,  state  that  a  major  management  concern 
for  software  development  is  that  all  requirements  for  a 
system  are  translated  into  detailed  specifications  of 
software  functions.  To  facilitate  this  they  recommend  that 
a  requirements  trace2ibility  matrix  be  created  to  map  system 
requirements  to  software  functions  and  serve  as  "the  basis 
for  a  completeness  indicator"  (Macmillan  and  Vosburgh,  1986, 
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p.  47).  The  completion  indicator  measures  progress, 

"because  the  percentage  of  requirements  addressed  is  an 
indication  of  the  amount  of  work  accomplished"  (Macmillan 
and  Vosburgh,  1986,  p.  48). 

West  (1991)  also  suggests  the  use  of  matrix  analysis 
to  "develop  design  requirements  from  customer  requirements, 
product  functions  from  design  requirements,  test 
requirements  and  process  requirements  from  customer  and 
design  requirements,  and  so  on"  (West,  1991,  p.  l).  The 
matrices  are  then  linked,  with  the  output  on  one  as  the 
input  of  another,  therefore  incorporating  the  whole 
development  process. . .The  rationale  for  decisions  can  be 
traced  back  all  the  way  from  shipping  the  product  back  to 
the  actual  customer  requirements"  (West,  1991,  p.  6).  West 
uses  these  matrices  in  his  Quality  Function  Deployment  (QFD) 
Methodology  for  software  development.  QFD  is  not  a 
requirements  gathering  process,  but  rather  is  "a  methodical 
way  to  ensure  product  functions  address  customer  needs  and 
that  no  requirements  are  ignored  or  overlooked  in  the 
development  process"  (West,  1991,  p.  6). 

A  method  recommended  by  Greenspan  and  McGowan  (1978) 
emphasizes  the  careful  definition  of  relied>ility 
requirements  through  the  use  of  Structured  Analysis  and 
Design  Techniques  (SADT).  This  technique  is  a  means  of 
structuring/documenting  the  development  process  with  a  major 
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emphasis  on  traceability  that  allows  changes  to  any  part  of 
the  design  to  be  traced  throughout  the  entire  system. 
Traceability  is  "the  property  of  a  system  description 
technique  which  allows  changes  in  one  of  the  three  system 
descriptions — requirements,  specification,  implementation— 
to  be  traced  to  the  corresponding  portions  of  the  other 
descriptions."  (Greenspan  and  McGowan,  1978,  p.  79) 

"Hierarchical  Progression  Analysis  (HPA)  is  a 
methodology  which  provides  traceedaility  through  a  software 
system  by  relating  the  data  and  control  flows  between  the 
various  disciplines  needed  to  develop  and  verify  a  system" 
(Andrews,  1984).  It  also  addresses  the  problem  of 
maintaining  traceability  during  the  translation  of 
requirements  into  design,  design  into  code,  and  the 
"subsequent  hierarchical  proof  of  the  correctness  and 
completeness  of  that  translation"  (Andrews,  1984).  HPA 
fills  the  traceability  void  in  the  systems  development 
process  in  that  it  enables  the  developer  to  maintain 
continuity  throughout  implementation,  providing  testers  with 
a  method  of  ensuring  each  requirement  is  tested,  providing 
managers  with  a  tool  to  evaluate  the  impact  of  proposed 
changes,  to  measure  wor)c  to  be  done  and  to  establish  a  high 
level  of  confidence  in  the  correctness  of  the  completed 
system.  (Andrews,  1984) 
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Jackson  presents  a  method  of  traceability  using 
keyphrases  to  express  relationships  between  entities.  The 
keyphrases,  extracted  to  a  file,  are  compared  and 
traceability  information  is  provided.  A  Relational 
Information  Management  System  (RIMS),  centered  on  an  Oracle 
DBMS,  loads  the  keyphrases  into  a  datedsase  and  provides 
early  warning  of  impact  and  helps  to  forecast  the  cost  of 
changes.  (Jackson,  1991,  p.  3) 

Edwards  and  Howell  (1992)  maintain  that  a  key  issue 
in  developing  a  correct  long  lasting  system  is  to  ensure 
consistency  between  requirements  and  design.  They  have 
developed  the  requirements  specification  and  trace^d}ility 
methodology  (ReSpecT).  Under  the  ReSpecT  methodology  the 
requirements  aspect  of  system  development  is  divided  into 
three  pairts:  conceptual  view,  formal  representation,  and 
design  elements  and  system  to  which  requirements  are  traced. 
(Edwards  and  Howell,  1992,  p.  3-1) 

This  methodology  is  vastly  different  from  previous, 
informal  methods  consisting  mainly  of  English  text.  ReSpecT 
methodology  allows  for  the  designer  to  identify  ambiguities 
while  also  checking  for  consistency  of  information.  These 
cap2d>ilities  would  be  beneficial  in  the  maintenance  of  these 
systems.  ReSpecT  techniques  ensure  the  final  design  meets 
the  requirements  specified  by  the  customer. 
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2.  MODELS 

Liu  and  Horowitz  (1969)  noted  that  there  is  great 
concern  about  the  lack  of  an  appropriate  model  of  the 
software  development  process  for  the  development  of  large- 
scale  software  and  stated  many  reasons  why  it  is  important 
that  a  good  model  be  available.  Briefly  these  reasons  are: 


•  A  model  is  a  means  of  communication  between  the 
stakeholders. 

•  A  model  provides  assistance  in  the  management  of  the 
process  by  providing  milestones  that  can  be  examined  to 
determine  the  rate  of  progress  of  the  project. 

•  A  model  gives  software  engineers  a  foundation  for 
building  tools  that  support  and  enhance  the  software 
process.  (Liu  and  HorowitZ/  1989,  p.  1280) 

Whereas  a  single  model  might  not  provide  all  the  angles  of 

software  development,  Liu  and  Horowitz  (1969)  suggest  the 

following  essential  features  for  a  successful  model: 

•  Describe  an  evolutionary  design  process. 

•  Provide  for  a  large-scale  project  that  functions  with 
parallel  processes. 

•  Indicate  all  artifacts  produced  at  various  points  in 
the  process. 

•  Indicate  activities  and  resources  affected  by  failed 
activities  and  then  allowing  for  their  reevaluation. 

•  Indicate  that  activities  exist  with  diverse  conditions. 

•  Indicate  the  extent  and  nature  of  resources  involved  in 
a  subtask,  including  people,  consumable,  and 
nonconsumed^le  resources.  (Liu  and  Horowitz,  1989, 

p.1281. ) 
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Liu  and  Horowitz  propose  the  DesignNet  model  that 
attempts  to  satisfy  all  of  the  above  criteria.  DesignNet 
is  an  open  system  model  which  is  designed  for  describing  and 
monitoring  the  software  development  process  using  AND/OR 
graphs  and  Petri  net  notation  **to  provide  the  description  of 
a  project  work  breakdown  structure  and  the  specification  of 
relationships  among  different  project  information  types 
(activity,  products,  resource  and  status  report 
information)."  (Liu  and  Horowitz,  1969,  p.  1280)  It 
provides  an  automated  information  tracking  mechanism  that 
records  project  history.  With  this  information  the  project 
manager  can  query  the  project  database  to  analyze  and  reason 
about  the  project's  progress.  Liu  and  Horowitz  show  how  the 
waterfall  life  cycle  model  maps  onto  a  DesignNet  and  the 
Implications  for  project  planning,  cost  estimation,  project 
network  construction,  re-initiation  of  activities,  and 
traceability  across  the  life  cycle.  (Liu  and  Horowitz, 

1989,  p.  1292) 

Horowitz  and  willieunson  (1986)  describe  the  data 
abstraction  model  used  in  Software  Documentation  Support 
(SODOS),  a  computerized  system  which  supports  the  definition 
and  manipulation  of  documents  used  in  developing  software. 
SODOS  "permits  traceability  through  all  phases  of  the 
software  life  cycle,  thus  facilitating  the  testing  and 
maintenance  phases"  (Horowitz  and  Willi2unson,  1986,  p.  849). 
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Most  system  development  life  cycle  models  consist  of 
the  following  stages:  analysis,  design,  implementation, 
test  production,  testing  and  reviews.  Wright  (1991) 
suggests  that  a  model  should  augments  this  traditional 
lifecycle  with  a  new  stage  which  he  describes  as 
"allocation,  the  task  of  mapping  requirements  onto  something 
that  is  a  necessary  evil  to  that  which  is  vital  to  both  the 
life  cycle,  and  the  success  of  requirements  traceability" 
(Wright,  1992,  p.  2).  This  new  model  would  rely  on  the 
review  phase  to  ensure  the  correctness  of  the  allocations  by 
determining  when  a  deliverable — something  that  is  produced-- 
becomes  an  acceptable — something  that  is  produced  and  that 
is  wanted— product .  (Wright,  1991,  p.  2) 

Ramesh  and  Dhar  (1992)  present  a  conceptual  model, 
REpresentation  and  MAintenance  of  Process  knowledge  (REMAP) 
that  relates  process  knowledge  to  the  objects  that  are 
created  during  the  requirements  engineering  process.  This 
model  includes  as  part  of  it  the  Issue  Based  Information 
Systems  (IBIS)  designed  to  record  argxunentation  related  to 
deliberations.  Support  for  various  stakeholders  involved  in 
software  projects  can  be  provided  by  capturing  the  history 
about  design  decisions  in  the  early  stages  of  the  systems 
development  life  cycle  in  a  structured  manner.  (Ra'nesh  and 
Dhar,  1992,  p.  1) 


31 


Ramesh  and  Edwards  (1993)  state  that  a  model  that 
represents  tTAceaLj.  information  at  the  level  of  systems 
design  relating  requirements  to  all  system  components  needs 
to  be  developed.  "A  comprehensive  scheme  fcr  maintaining 
traceability,  especially  for  complex,  real-time  systems, 
requires  that  all  system  components  (not  just  software), 
created  at  various  stages  of  the  development  process,  be 
linked  to  the  requirements"  (Ramesh  and  Edwards,  1993,  p. 
256)  This  model  should  include  semantic  models  that  support 
the  various  stakeholders  in  systems  development  activities. 
Models,  supported  by  reasoning  mechanisms  to  support  various 
stakeholders,  that  capture  essential  features  of  systems 
development  process,  such  as  the  design  rationale  are 
components  of  a  useful  traceability  scheme.  (R2unesh  and 
Edwards,  1993,  p.  259) 

0.  TRACEABILITY  TOOLS  AND  CURRENT  EXPECTATIONS 

One  important  aspect  of  any  software  development 
environment  designed  to  assist  with  software  development  to 
government  standards  is  the  eUsility  to  automatically 
document  requirements  traceability.  (Roetzheim,  1991, 
p.  129) 

A  number  of  traceability  tools  with  a  wide  variety  of 
capabilities  have  been  developed  by  the  industry,  both  for 
in-house  use  and  as  commercial  products.  Since  these  tools 
vary  widely  in  their  applications,  and  as  yet  there  are  no 
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industry  standards  for  them,  we  do  not  attempt  to  make 
comparisons  nor  appraisals  of  their  features.  Rather,  a 
brief  description  of  capabilities  of  a  few  tools  is 
presented  to  provide  an  overview  of  features  available  in 
tools  today. 

1.  ARTS 

One  of  the  earliest  systems  to  capture  and  use 
traceability  data  was  Automated  Requirements  TraceeUsility 
System  (ARTS),  a  bookkeeping  program  developed  to  manage  the 
requirements  of  a  large,  error-prone  aerospace  system.  ARTS 
operates  on  a  data  base  that  includes  systems  requirements 
and  their  characteristics.  It  allows  for  automated  tracking 
of  requirements  as  they  are  partitioned  and  apportioned  to 
lower-level  requirements.  ARTS  provides  database  management 
and  output  operations  on  requirement-related  attributes 
selected  by  the  user.  The  major  function  of  ARTS  "is  to 
provide  rapid  and  accurate  traceability,  upward  and 
downward,  in  a  requirements  hierarchy  or  tree.”  (Dorfman  and 
Flynn,  1984,  p.  63)  Like  ARTS,  other  tools  often  focus  on 
the  dated^ase  management  issues  related  to  maintaining  links 
between  requirements  and  the  different  components  of  the 
system. 

2 .  Teamwork/RQT 

Some  of  the  traceability  tools  provide  for  manual 
parsing  and  grouping  of  functional  requirements.  One  such 
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tool  is  Cadre's  Teamwork/RQT.  Other  capabilities  include 
point-and-click  allocation  of  requirements  to  targets, 
navigation  through  allocation  channels  to  integrate  the 
entire  life  cycle,  and  the  ability  to  propagate  allocations 
between  parent  and  child  entities.  Teeunwork/RQT  is  a 
comprehensive  package  providing  automatic  model  consistency 
checking  that  "provides  a  simple  means  of  automatically 
generating  a  traceability  report  on  (those  requirements) 
which  have  been  satisfied  by  which  parts  of  the  model" 
(McCausland,  1991,  p.  1).  ^ 

Cadre  describes  Teamwork/RQT  and  its  concept  of 
requirements  traceability  as  being  able  to  reveal  the 
"mapping  between  requirements  and  the  delivereUale  components 
which  are  intended  to  satisfy  them"  (Cadre  Technologies, 
Inc.,  1990,  p.  6).  They  further  state  that  compliance  is 
proven  in  a  two-step  process: 

•  Show  the  correspondence  of  requirements  to  delivered^le 
components.  A  table  which  shows  this  correspondence  is 
called  a  traceability  matrix. 

•  Show  that  the  corresponding  delivered>le  components 
correctly  satisfy  the  requirements.  (Cadre 
Technologies,  Inc.,  1990,  p.  6) 

3.  RT 

Teledyne  Brown  Engineering's  Requirements  Tracer 
(RT)  is  designed  to  be  used  throughout  the  entire  system 
life  cycle  to  "define,  analyze,  and  trace  system 
requirements."  (Teledyne  Brown  Engineering,  1991,  p.  1)  RT 
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uses  a  database  of  natural  language  requirements  that, 
through  the  use  of  pre-defined  criteria,  allow  for  the 
establishment  of  relationships  between  requirements.  A 
requirements  traceability  matrix  is  created  that  provides 
assistance  in  verifying  the  proper  allocation  of  all 
requirements.  The  user  of  the  tool  then  generates 
customized  reports  which  provide  user-^selected  sets  of 
information  to  support  requirements  traceability.  (Teledyne 
Brown  Engineering,  1991,  p.  1) 

Capedjilities  of  RT  include  such  tracing  mechanisms 
as  parent/child  relationships  (and  how  to  determine  them), 
functional  hierarchy,  keywords,  attributes,  querying, 
requirements  extraction,  and  customized  report  generation. 
Requirements  can  be  allocated  to  functions  or  sxibfunctions 
by  either  direct  entry  or  selection  from  a  previously 
defined  list. 

4.  RTM 

Marconi  Systems  Technology's  Requirements  and 
Traceability  Management  (RTM)  is  a  traceed>ility  tool  that 
provides  project  configured)ility  (specifying  where 
trace2d>ility  is  wanted),  requirements  engineering, 
requirements  traceability,  and  documentation.  By  using  more 
than  one  type  of  link  between  objects,  RTM  assists  in 
ensuring  that  the  software  produced  meets  the  expectations 
of  the  user. 
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5.  KDO-lOO 

The  objectives  of  traceability  with  RDD-100  include 
to:  indicate  which  portions  of  the  system  design  satisfy 
specific  requirements,  record  issues  and  resolutions  as  the 
foundation  for  subsequent  changes  to  originating 
requirements,  identify  the  set  of  decisions  that  led  to  the 
baseline  requirements,  link  verification  methods  to  design 
elements,  and  provide  consistency  between  documents. 

6.  Shortfalls  With  Current  Tools 

Current  traceability  techniques  tend  only  to  provide 
mechanisms  to  represent  relationships  among  objects  without 
providing  any  guidance  on  what  useful  relationships  are  and 
how  this  information  will  be  useful  during  the  lifecycle  of 
a  system.  Contemporary  methods  yield  some  traceability 
through  simple  linking  techniques  that  relate  requirements 
to  design. 

According  to  Edwards  and  Howell  (1992),  shortfalls 
in  today's  technology  for  requirements  traceability 
techniques  include  that  current  tools: 

•  do  not  capture  how  the  requirement  is  satisfied  by  the 
design  just  the  fact  that  some  relationship  exists 

•  lack  the  ability  to  trace  back  from  the  actual  pieces 
of  design  and  implementation  to  the  requirements 

•  do  not  have  a  method  for  tracing  from  a  particular 
piece  of  hardware  or  humanware  back  to  the  requirement. 
(Edwards  and  Howell,  1992,  p.  2-4) 
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E.  COMCLUSXOH 

A  comprehensive  model  for  maintaining  traceability, 
especially  for  complex,  real~time  systems,  requires  that  all 
system  components  (not  just  software),  created  at  various 
stages  of  the  development  process,  be  linked  to  the 
requirements.  To  achieve  this  it  is  essential  that 
traceability  be  maintained  through  all  phases  of  the  systems 
development  process,  from  the  requirements  as  stated,  or 
contracted,  by  the  customer,  through  analysis,  design, 
implementation,  and  testing  to  the  final  product. 

Additionally,  it  is  critical  that  consistency  between 
the  requirements  and  the  design  is  maintained,  especially  in 
situations  where  an  organization  relies  on  outside 
contractors  for  developing  systems.  Having  a  systematic  way 
of  validating  that  each  requirement  is  met  by  the  design  is 
important,  not  only  to  ensure  that  the  system  performs 
correctly,  but  also  to  determine  whether  contractual 
obligations  have  been  met. 

The  need  to  provide  traceability  is  recognized  in 
standards  that  regulate  the  development  of  systems  for  the 
U.S.  Government;  yet,  there  is  no  clear  definition  of  the 
types  of  information  or  relationships  between  the  various 
system  components  that  are  part  of  a  traceed>ility  model. 
Neither  the  stemdards  that  require  traceability  as  a  part  of 
emy  systems  development  effort  nor  the  current  literature 
elaborate  on  the  specific  types  of  traceability  linkages  to 
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be  maintained.  Though  current  tools  provide  mechanisms  to 
represent  various  types  of  linkages  between  system 
components,  the  interpretation  of  the  meanings  of  such 
linkages  is  left  to  the  user.  Finally,  the  focus  of  the 
majority  of  the  literature  reviewed  catered  to  traceability 
at  the  level  of  software  design,  rather  than  at  the  level  of 
system  design. 
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III.  REQUIRENEHTS  TRACEABILITY  MODEL 


A.  IKTRODUCTIOM 

A  principal  challenge  in  this  thesis  is  the  development 
of  a  model  that  represents  and  provides  the  semantics  of 
various  traceability  linkages  or  relationships  between 
requirements  and  system  components.  A  basic  premise  in  our 
research  is  that  development  of  a  model  of  traceeUoility 
could  be  geared  towards  the  needs  of  stakeholders  at  various 
stages  in  the  systems  development  process.  Using  focus 
groups,  we  conducted  a  study  to  identify  the  traceed)ility 
information  needs  of  various  stakeholders  during  systems 
development . 

In  this  chapter  we  discuss  results  from  the  analysis  of 
data  collected  during  our  study.  First  we  reviewed  the 
context  in  which  traceability  information  is  likely  to  be 
used  during  systems  development;  i.e.,  from  the  perspectives 
of  key  stakeholders  in  terms  of  the  different  types  of 
traceability  information  that  would  be  of  interest/use  to 
them.  Then  we  looked  at  specific  traceed>ility  linkages  or 
relationships  between  various  system  design  products  and 
processes  that  would  support  these  needs. 

A  traceability  information  model  has  been  developed 
based  on  this  analysis.  Following  is  a  discussion  of  the 
semantics  of  various  types  of  traceability  information 
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represented  as  linkages,  mechanisms  for  their  capture,  and 
their  use  in  systems  development  activities.  We  have 
segregated  the  model  into  three  parts  for  clarity  of 
presentation:  Requirements  Management,  Design/ Implementation 
and  Allocation,  and  Compliance  Verification.  Each  par^  is 
further  segregated  by  functional  features.  In  this  chapter, 
traceability  linkages  will  be  identified  by  uppercase,  bold 
faced  letters  (LIMKAOES),  while  components  that  they  link 
are  indicated  with  uppercase,  italic  letters  (COMPONENTS) . 
For  every  link  in  the  model  an  inverse  may  be  defined. 

B.  REQUIREMENTS  MANAGEMENT 

A  recurring  theme  among  the  subjects  was  that 
traceability,  when  implemented  correctly,  would  greatly 
benefit  requirements  management  facilitating  requirements 
understanding,  capture,  tracking  and  verification.  The 
following  is  a  discussion  of  the  Requirements  Management 
Model  presented  in  Figure  1. 

1.  Organisational  Objective 

ORGANIZATIONAL-NEEDS  must  JUSTZPI  SYSTEM-OBJECTIVES 
as  systems  are  built  primarily  to  satisfy  these  needs.  They 
are  further  broken  down  into  OPERATIONAL-NEED,  the 
functional  needs  of  the  organization  and  MISSION-NEED,  the 
strategic  needs,  as  denoted  by  the  IS-A  hierarchy.  These 
two  needs  SUPPORT  each  other  and  are  the  foundation  used  to 
corroborate  the  Organizational-Heeds. 
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System  Objectives 


Figure  1:  Requirements  Management  Model 


2.  SystM  Objttctiv* 

STAKEHOLDER,  be  it  the  customer/  progreun  manager/  program 
sponsor/  etc.  SPECIFIES  the  SYSTEM^BJECTIVES .  The 
REQUIREMENTS  for  the  system  are  OEMERATED-BT  these  System 
Objectives. 

3.  Critical  Success  Factors  (CSF) 

STAKEHOLDERS  IDEMTIFT  various  CSFs  for  the  system. 
These  stakeholders  could  be  anyone/  but  most  likely  would  be 
the  Customer/  System  Developer/  and/or  Project  Manager. 
("Stakeholders  have  some  issues  or  values  like,  no  mistakes 
or  system  errors/  performance  is  not  the  most  important 
thing/  it's  no  mistakes.")^  These  CSFs  could  be  whatever  is 
considered  critical  to  the  projects'  development:  Mission 
Criticality/  Cost/  Time/  Weight/  Voltage/  etc.  They 
INFLUENCE  DECISIONS  made  during  requirements  management. 
Further/  the  Systems'-Objectives  are  constrained  or  DRIVEN  by 
the  CSF  (Critical  Success  Factors).  The  overall 
requirements  traceeUsility  focuses  on  the  CSFs  IDENTIFIED  by 
the  Stakeholder/  and  facilitates  requirements  being  TRACKED- 
BT  those  CSFs. 

Mission  criticality  (a  CSF)  of  requirements  could  be 
used  in  classifying  and  monitoring  them.  Similarly/  CSFs 
such  as  weight  emd  cost  can  be  used  in  tracking  and  managing 

^  This  is  a  direct  quota  from  a  subject  participating  in  a  focus  group. 
Henceforth,  all  quotes  from  a  subject  will  be  enclosed  in  parentheses 
and  quotation  marks,  but  no  specific  reference  will  be  made. 
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requirements.  Due  to  the  large  number  of  requirements 
associated  with  many  of  today's  projects,  it  is  important  to 
determine  those  which  are  critical  to  the  success  of  the 
project  and  to  trace  them  and  others  they  relate  to.  It  is 
necessary  to  decide  which  requirements  should  be  tracked  and 
which  are  of  lesser  importance,  ("...just  try  to  get  that 
information,  and  not  get  the  rest  of  the  requirements  that 
may  not  be  as  important.") 

("There's  a  dependency  of  total  dollars  that  are 
spent  or  the  total  of  whatever  that  is  spent.")  ("Basically, 
you've  got  schedule  margins,  cost  margins.")  ("A  lot  of 
decisions  have  been  made ... because  of  cost  and  weight, 
mostly  cost.")  ("It  will  be  a  combination  of  technical  and 
cost  trades.")  DECISIONS  are  always  made  considering  the 
CSFs  to  determine,  among  many  things,  whether  they  are 
feasible,  cost  effective,  or  desired>le. 

As  part  of  the  negotiation  process  eunong 
stakeholders  when  making  decisions,  there  are  many  tradeoffs 
made  depending  on  the  availability  of  resources  and  whether 
they  are  considered  to  be  CSFs.  ("Typically  we  enter  into  a 
complex  negotiation  process  of  what's  in  scope,  what's  out 
of  scope,  what's  affordedsle,  what's  not  affordable.  And  I 
believe  this  is  where  traceability  earns  its  keep.") 

As  all  reoruirements  are  not  equal  in  significance  or 
criticality,  various  requirements  may  be  traced  through  the 
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lifecycle  at  different  levels  or  granularity  of  detail  in 
order  to  optimize  resources  spent  on  such  capture.  It  may 
be  unnecessary  or  even  undesirable,  considering  the  overhead 
involved  in  maintaining  traceability,  to  maintain  linkages 
between  every  requirement  and  every  output  created  during 
the  systems  design  process. 

As  REQUIREMENTS  are  OBNERATBD-BT  SY STEM -OBJECTIVES , 
they  can  be  prioritized  throughout  the  lifecycle  to  provide 
stakeholders  with  a  view  to  understand  and  evaluate  whether 
the  system  supports  these  CSFs.  ("...the  smaller  subset  is 
the  driving,  high  risk  set  of  requirements  that  merit  more 
visibility  in  the  tracking  of  the  program. . .we  have  an 
attribute  of  a  requirement  that  we  call  technical 
performance  measure  (TPM).  Is  it  high  risk,  do  we  want  to 
put  a  TPM  against  this  requirement?  The  TPMs  are  all 
programmed,  tracking,  giving  them  higher  visibility  to  see 
how  we're  doing.") 

4 .  Change 

One  of  the  biggest  challenges  in  managing  today's 
large,  complex  systems  is  the  way  that  requirements  are 
constantly  evolving  and  changing.  Each  focus  group  agreed 
that  to  accurately  reflect  this  volatility,  a  dynamic  model 
of  requirements  traceability  is  needed.  For  military 
applications,  not  only  is  the  nature  of  systems  requirements 
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dynamic,  but  even  the  organizational-needs  (mission  and 
operational)  and  the  systems-objectives  also. 

Systems  that  were  considered  successful  during  the 
Soviet  threat  era  are  no  longer  considered  useful  as 
strategic  and  mission  needs  are  evolving  rapidly.  It  is  not 
possible,  however,  to  abandon  all  investments  in  military 
systems  and  develop  new  systems  to  meet  current  needs.  The 
ability  to  identify  components  that  are  linked  to  various 
objectives  and  modify  them  to  suit  the  current  situation  is 
needed.  STAKEHOLDER  MODIFY  SYSTEH-OBJECTIVES  based  on 
revised  mission  needs.  When  this  happens,  the  modified 
SYSTEM-OBJECTIVES  GENERATE  changed  REQUIREMENTS. 

It  is  very  important  that  the  model  captures  such 
changes.  We  have  identified  basically  two  types  of  changes, 
those  that  fix  a  deficiency  in  system  design  (as  identified 
say,  during  testing)  and  those  that  occur  because  of  the 
dynamic  nature  of  the  system  that  is  being  developed.  The 
former  aspect  is  covered  in  the  discussion  on  design  and 
allocation  procedures. 

When  new  or  deleted  requirements  enter  the  system, 
they  are  AUTHORIZED-BT  at  least  one  STAKEHOLDER  and 
SUPPORTED-BT  the  SYSTEMS-OBJECTIVE .  CHANGES  to  REQUIREMENTS 
follow  such  revised  needs. 
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5.  Raquircments  Evolution 

Traceability  links  the  different  levels  of 
requirements  as  they  evolve  through  the  various  stages  of 
the  development  lifecycle.  This  provides  for  recursive 
links  between  the  requirements  as  they  change  and  evolve 
through  each  phase,  providing  a  historical  record  of 
requirements  information.  Linkages  map  the  requirement  back 
to  the  original  requirement  thus  allowing  the  users  to  have 
complete  understanding  of  where  the  requirement  comes  from. 

REQUIREMENTS  are  often  DERIVED  from  other 
requirements,  often  based  on  assumptions  made  by 
stakeholders  in  their  interpretations.  These  derived 
requirements  need  to  be  tracked  carefully  as  they  are  likely 
to  be  a  major  source  of  conflicts  and  issues,  and  subject  to 
changes  as  the  interpretations  and  assumptions  vary.  They 
are  also  the  cause  of  an  "explosion"  in  the  number  of 
requirements.  ("...if  you  can  start  with  30  pages  of 
requirements,  top  level,  then  you  can  go  to  your  prime  item 
development  specifications  and  you  could  consider  those  9000 
requirements  derived  from  those  30  pages,  but  then  you  go  in 
those  9000  and  there's  going  to  be  derived  requirements 
between  those  second  and  third  generation. . .you  have  an 
explosion  of  derived  requirements  and  relationships.") 

Requirements  that  are  derived  ( "create  a  collection 
of  requirements  at  a  different  level  which  defines  this  new 
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entity,  or  new  thing  at  a  lower  level.  Then  you  do  a  one 
for  one  traceability  of  the  originating  requirements  with 
the  requirements  that  partially  satisfies  it."). 

Some  REQUIREMENTS  are  ElABORATED  by  others, 
providing  further  explanation  or  clarification.  This  auded 
detail  assists  in  understanding  the  assumptions  and 
interpretations  made.  ("Sometimes  you  add  requirements 
really  because  you  find  them.  They  are  refined,  and  become 
more  specific  in  detail  then  in  fact  are  more  demanding  than 
the  original  requirement  might  have  been.")  Requirements 
also  DEPBHD-OH  others.  An  example  would  be  an  application 
requirement  may  depend  on  a  specific  software  that  in  turn 
depends  on  a  specific  hardware.  Identifying  these 
dependencies  is  important,  especially  when  implementing 
changes,  so  that  the  impact  of  the  change  to  the  entire 
system  can  be  determined. 

Breaking  down  larger  requirements  may  generate 
smaller  REQUIREMENTS  that  form  a  PART-OF  it.  This  provides 
information  of  how  the  pieces  fit  together  and  is  especially 
important  on  large,  complex  systems  that  require 
REQUIREMENTS  to  be  further  developed.  ("Higher  levels  are 
just  edastractions  of  lower  levels.")  Finally,  IS~A  links 
show  the  parent/child  hierarchical  relationships  between 
requirements.  ("Initially  it's  a  top>down,  hierarchical 
decomposition  starting  with  the  most  general  goals  of  the 
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customer,  flowing  down  to  a  set  of  systems  performance 
requirements. . .you  now  can  have  children  with  multiple 
parents,  whereas  originally  we  were  probably  looking  at 
children  with  a  single  parent.**)  An  example  of  an  IS-A 
hierarchy  would  be:  Computer  Software  Unit  (CSU)  is  a 
Computer  Software  Component  (CSC)  is  a  Computer  Software 
Configuration  Item  (CSCI)  is  a  Segment  is  a  System. 
(Roetzheim,  1991,  p.  23) 

CONSTRAINT  may  be  treated  as  a  type  of  REQUIREMENT 
(denoted  by  the  IS**A  link).  Every  focus  group  stated  how 
various  constraints  become  hard  requirements  because  they 
set  limits  within  which  the  system  can  be  developed. 

Systems  are  designed  and  decisions  made  with  constraints 
considered. 

€ .  Decision  Making 

REQUIREMENTS  GENERATE  (or  lead  to)  CONFLICTS/ISSUES, 
that  often  occur  due  to  differing  interpretations,  assump¬ 
tions,  interests,  viewpoints,  experience  and  objectives  of 
the  stakeholders.  Information  about  the  decisions  made, 
assumptions  in  place,  status  of  issues,  and  change  activity 
must  be  maintained  throughout  the  system  lifecycle  to  ensure 
that  customer  requirements  are  understood  and  satisfied. 
(**Traceed)ility  pays  for  itself  by  making  sure  you  understand 
how  the  requirement  is  interpreted,  how  it*s  being 
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implemented,  what  were  the  issues  that  were  considered  in 
the  design  to  satisfy  that.") 

DECISIONS  MADE-BT  STAKEHOLDERS  provide  a  basis  with 
which  requirements  are  RBPIirEO.  During  decision  making,  to 
KESOLVE  CONFLICTS/ISSUES,  various  ALTERNATIVES  that  could 
lead  to  their  resolution  are  EVALUATED.  Though  the  chosen 
alternative  is  well  documented  in  many  cases,  the  other 
alternatives  considered  are  not  recorded.  It  is  important 
to  capture  this  information  as  it  may  become  relevant  in  a 
changed  context.  Availability  of  the  information  may  avoid 
expensive  rework  on  the  same  decisions.  ("We  debated  that 
for  two  weeks  now.  Why  was  it  thrown  out  years  ago  when  we 
got  one  camp  arguing  to  put  it  back  in  and  another  to  keep 
it  out.  And  if  we  could  have  gone  back  and  assessed  why  we 
made  that  decision  two  years  ago  it  would  have  saved  us  some 
time . " ) 

It  is  important  to  track  the  RATIONALE  that  SUPPORT 
the  DECISIONS.  This  RATIONALE  is  BASED-OH  the  ASSUMPTIONS. 
Also,  it  is  desirable  to  keep  track  of  the  assumptions  as 
explicitly  as  possible  for  these  are  the  most  likely 
candidates  for  reevaluation  and  change,  leading  to  changed 
requirements.  Besides  the  RATIONALE  that  support  decisions 
to  resolve  issues,  the  rationale  behind  various  requirements 
may  also  be  represented  to  identify  their  justification. 
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Further,  the  ASSUMPTIONS  that  SUPPORT  RE(^IREMENTS  must  also 
be  explicitly  captured. 

Over  the  lifecycle  of  a  project,  the  personnel, 
requirements,  assumptions,  etc.  change  and  this  change  leads 
to  a  lot  of  rework  as  this  decision  history  information  is 
typically  not  maintained.  ("We  already  looked  at  that 
tradeoff,  that  approach,  but  the  person  that  did  it  is  going 
and  the  person  that  reviewed  it  is  gone,  so  we  chum  the 
whole  thing  again.")  ("This  is  a  lengthy  look  at  all  these 
phases  with  a  lot  of  people  that  contribute  to,  touch, 
change,  add,  use  this  information.  If  you  just  have  an 
understanding  about  the  linkages  and  relationships,  that  to 
me  is  just  the  information  model  that  you're  going  t«' 
maintain.  But  who  produces  it,  when  do  they  produce  it,  in 
what  order,  how's  the  information  shared  intelligently  are 
all  equally  important  issues.") 

7 .  Source 

A  source  is  the  person  or  thing  that  "documents" 
each  component  in  the  model.  There  are  many  manifestations 
of  SOURCE:  documents,  manuals,  persons,  meetings, 
conversations,  standards,  contracts,  etc.  SOURCE  is 
traceable  to  every  node  and  link  of  the  model.  It  is 
desirable  to  be  able  to  go  back  to  the  document,  or  whatever 
the  SOURCE~IS  and  examine  the  actual  text  or  quote  from  a 
stakeholder.  ("Normally  what  happens  is  you  have  a  set  of 
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requirements  that  go  back  to  one  source  and  you'd  interpret 
what  they  said,  so  you  need  to  have  that  original  source  to 
be  able  to  go  back  and  verify  that  your  interpretation  was 
correct.")  ("There  are  all  kinds  of  customers  out  there... so 
it's  real  important  to  know  which  of  those  stakeholders  has 
that  requirements  because  you  have  all  kinds  of  conflicts.") 

One  would  like  to  get  back  to  the  source  for 
understanding,  clarification,  etc.  STAKEHOLDERS  CREATE 
SOURCES  of  requirements.  It  is  necessary  to  know  who 
created  these  sources  for  future  reference  as  clarification 
might  be  needed.  ("You  want  to  know  who,  when,  where  and 
possibly  why  that's  a  requirement.")  STAKEHOLDER  IS**A 
SOURCE  since,  at  any  time  during  development,  they  can  be  a 
source  of  a  requirement,  rationale,  etc. 

Also,  during  the  systems  development  process  they 
often  IRTERPRET  items  of  various  sources  by  stakeholders,  be 
it  a  requirement,  a  standard,  a  need,  etc.  Even  when  two 
different  stakeholde:  &  use  the  same  source  (say,  standard  or 
meeting  minutes)  they  may  interpret  it  differently.  Often 
the  difference  in  interpretation  is  the  cause  of  conflicts 
between  stakeholders,  even  in  a  cooperative  setting. 
Therefore  it  is  important  to  capture  this  information  to 
provide  clarification.  ("You  can  look  at  a  given  set  of 
requirements  and  they  might  be  meaningless  if  you  don't 
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really  know  what  the  customer  needs  because  you  can 
interpret  them  wrong,  or  at  least  two  or  three  different 
ways.") 

The  source  of  the  requirement  oftentimes  is  not  its 
originator,  but  may  be  a  intermediary  who  makes  the 
interpretation,  and  therefore  provides  another  twist  to  the 
requirements.  It  is  important  to  capture  information  about 
this  intermediary  to  help  identify  the  history  of 
requirements . 

Another  reason  to  have  the  source  of  the  requirement 
is  to  provide  account2d)ility.  This  provides  the 
stakeholders  with  information  edx)ut  how  the  requirements  and 
design  have  evolved,  what  changes  have  been  made,  why  and 
how  these  were  made,  and  the  status  of  their  development. 
("If  you  don't  have  requirements  traceability  to  link  back 
to  that  high  level  requirement,  it's  going  to  be  very 
difficult  to  give  the  customer  an  impact  statement  of  that 
change . " ) 

C.  DESION/ALLOCATION 

In  this  study  of  traceability  we  have  looked  at  the 
whole  systems  development  lifecycle.  ("For  the  system  to 
work  you  have  the  hardware  issue,  software  issues,  system 
issues,  everything  has  to  work  together.")  The  Design/ 
Allocation  Model  is  presented  in  Figure  2  and  Figure  3. 


52 


1*  D^sign/lBplwMntatioa 


We  view  design  as  any  activity  that  creates 
artifacts.  The  implementation  process  may  be  seen  as  a 
lower  level  design  activity.  Further,  design  defines  the 
system,  while  implementation  creates  it.  Therefore,  the 
traditional  distinction  between  design  and  implementation  is 
not  made. 


Figure  2:  Design  Allocation  Model 
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REQUIREMENTS  DRIVE  DESIGN / IMPLEMENTATION .  These  are 
CONSTRRZIIEO  by  STANDARDS j  e.g.,  military  standards, 
policies,  procedures,  methods,  etc.  These  constraints  may 
be  documented  in  various  sources  (as  noted  by  the  ZS-A 
hierarchy) . 

2 .  Systea/Subsystem/Components 

SYSTEM/SVBSYSTEM/COMPONENTS  (here  on  referred  to  as 
COMPONENTS)  are  the  building  bloc)cs  of  the  system.  They  are 
DEPZNBO  by  the  DESIGN /IMPLEMENTATION  process.  REQUIREMENTS 
are  ALLOCATEO-TO  COMPONENTS.  The  components  could  be 
anything,  a  piece  of  hardware,  software,  humanware,  etc. 

("At  the  allocation  step  you're  going  to  allocate  to  people, 
to  processors,  to  memory,  to  hardware,  etc.") 

COMPONENTS  DEPEIID->OK  other  components,  in  that  the 
performance  of  one  may  depend  on  anuther.  Some  of  these 
dependencies  are  more  obvious  than  others.  Those  that 
actually  interface  with  other  components,  say  actually  talk 
to  each  other,  have  explicit  dependencies  and  are  easier  to 
recognize  than  those  that  do  not  directly  interface.  For 
instance,  an  operating  system  on  one  component  that  may 
affect  the  choice  of  hardware  on  another  even  though  there 
may  be  no  direct  interfaces  between  them.  This  information 
is  needed  so  that  when  a  component  is  modified,  deleted, 
and/or  added  than  there  is  a  way  of  determining  how  the 
system  is  affected  by  these  dependencies.  PART-OP  maps  the 
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components  that  are  pieces  of  a  larger  component  which,  when 
put  together,  make  a  whole.  This  information  allows  the 
designers  to  know  inter-component  dependencies.  ("As  I 
change  a  part  or  break  it  into  sub-parts,  I  would  like  to 
have  some  sort  of  traceability  or  mesh  structure  which  gives 
some  sort  of  relationships...!  would  like  to  know  what  is 
the  characteristic  of  each  component.")  Finally,  an  ZS-A 
hierarchy  specifies  that  components  are  decomposed  at 
different  levels;  e.g.,  from  system  to  subsystem  to  item  and 
to  unit. 

The  subjects  of  our  research  stressed  that 
identifying  STAKEHOLDERS  RESPONSIBLE-POR  the  various 
COMPONENTS  of  the  system  was  important  to  ensure 
accountability.  This  information  provides  an  ownership  to 
the  system  components  that  satisfy  specific  requirements. 
Here,  ownership  does  not  refer  to  the  originator  as  a 
requirement,  but  the  person  who  is  responsible  for 
satisfying  it.  ("If  I've  got  a  high  level  requirement  and 
I'm  going  to  allocate  that  down  to  the  next  level  of 
specification  then  I  have  assigned  ownership  for  at  least 
the  satisfying  of  at  least  part  of  that  requirement  to  that 
lower  level  specification.  And  I  would  expect  that  whoever 
owned  that  specification  to  take  responsibility  for  that 
allocation.")  ("The  customer  gives  us  requirements  to  do  a 
program  or  a  system,  then  we  take  those  requirements  and 
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parse  then  out  to  the  components  of  the  system.  Then  that 
group  can  look  at  that  component  in  the  same  way  we  look  at 
the  system.") 

It  is  also  important  to  track  the  allocation, 
distribution  and  utilization  of  resources.  RESOURCES  are 
USED-BT  and  ALLOTEIHTO  COMPONENTS.  This  allows  the  actual 
utilization  of  resources  to  be  tracked.  ("At  the  allocation 
level  there  needs  to  be  parameters  that  associate  budgets  of 
resources  that  are  going  to  be  consumed . . . and  then  you ' re 
going  to  have  to  test  to  see  that  you’re  somehow  compatible 
with,  complying  with  and  not  grossly  out  of  bounds  with  your 
budgeting.")  ("I  want  traceability  to  give  me  some  level  of 
assurance  of  particular  steps  in  the  design  process  that  I'm 
meeting  or  likely  to  meet  system  goals  or  to  help  me  to 
allocate  resources  or  capabilities  in  such  a  way  that  I 
meiximize  the  likelihood  of  meeting  system  goals.") 

RESOURCES  are  allocated  in  line  with  CSFs,  such  as 
time,  money,  weight,  criticality,  long  term  maintainability, 
etc.  ("If  cost  happens  to  be  the  major  system  driver  then 
what  I  am  really  interested  in  is  keeping  track  of  actual  or 
supposed  cost  of  the  components.  If  on  the  other  hand 
memory  space  is  the  primary  driver  they  might  not  really  pay 
as  much  attention  to  cost,  as  how  my  decisions  impact  the 
allocation  of  memory  space.") 
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Our  subjects  also  mentioned  that  it  was  important  to 
understand  what  FUNCTIONS  the  COMPONENTS  PERFORM  aund  how 
these  SATISFIED  REQUIREMENTS,  The  COMPONENTS  work  together 
to  SATISFY  the  non-functional  requirements  also.  A 
component  may  partially  SATISFY  requirements,  and  as  the 
design  progresses,  requirements  must  be  fully  satisfied. 

3 .  External  Systems 

The  COMPONENTS  DEPEMD-OM  EXTERNAL  SYSTEMS  in  that 
they  often  interfaces  with  other  systems.  As  already 
discussed,  direct  interfaces  are  easier  to  recognize  than 
those  that  have  ambiguous  dependencies.  However, 
information  about  all  interfaces  is  important  to  maintain. 
("What's  happening  new  is  that  instead  of  being  a  single 
quantity,  a  single  product  line,  the  change  in  technology 
that  we  see  is  bringing  about  a  new  paradigm... a  particular 
product  line  is  going  to  be  brought  on  board  a  ship  and  it's 
going  to  have  to  plug  into  an  already  existing  system... the 
things  they  need  to  know  is  what  is  the  functionality  that 
the  system  needs  to  have,  what  is  the  demand  on  these 
services  that  they  would  have  and  the  range  of  the  demand.") 

4.  Design/Al location  Decisions 

Similar  to  the  requirements  model  presented  in 
Figure  1,  there  is  a  decision  process  for  design  and 
allocation.  This  is  presented  in  Figure  3.  The  components 
and  links  of  this  process  are  the  same  as  that  presented  in 
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the  Requirements  Memagement  Model  and  the  discussion 
presented  in  paragraph  I I I. A. 6  is  applicable,  except  that 
they  relate  to  DESIGN /IMPLEMENTATION.  ("Traceability  would 
come  in  handy  for  determining  the  reasons  for  your  design. " ) 
("That's  the  design  knowledge  capture  that  we  were  supposed 
to  maintain.  What  is  basically  here  is  the  design  the  way 
it  is  and  here's  the  decisions,  the  thought  that  went  into 
that  deci-sion.  And  then  when  you  changed  them,  here's  how 
we  changed  them.")  ("Another  use  of  traceability  in  design 
is  allocating  functions  in  such  a  way  that  you're  sure  that 


Figure  3:  Design/Implementation  Decision  Making  Model 
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they  support  each  other  and  don't  interfere  with  each 
other.") 

O.  COMPLIJUICS  VERXFICATZOH 

Throughout  our  research  it  became  very  obvious  that  the 
"testing"  phase  of  systems  development  was  affected  by  all 
requirements.  Each  requirement  usually  has  a  set  of 
"testing"  parameters  associated  with  it  that  are  used  to 
determine  whether  they  have  been  satisfied  by  the  system. 
The  Compliance  Verification  Model  (Figure  4)  is  discussed 
below. 
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Figure  4:  Compliance  Verification  Model 


1.  Coaplianc*  V«riflci>tion  Proc«dur«s 

Procedures  for  verifying  the  compliance  of  the 
system  components  with  requirements  are  defined;  the  plans, 
approach,  and  methods  are  described.  TEST,  INSPECTION, 
SIMULATION,  and  PROTOTYPE  are  all  COMPLIANCE  VERIFICATION 
PROCEDURES  (here  on  referred  to  as  CVP)  as  noted  by  the  XS~A 
link.  ("We  write  the  test  specifications  by  taking  apart 
the  SRS  and  Component  Specifications.")  ("You've  got  to  be 
able  to  specify  what  you're  going  to  test  to.  You've  got  to 
be  able  to  calibrate  in  terms  of  if  the  performance  is  what 
you  need.")  These  CVPs  are  0EV£L0PE1>->P0R  each  REQUIREMENT. 

( "Once  you  determine  what  requirements  need  to  be  tested  it 
requires  test  procedures.  If  something  is  untestable  or  we 
elect  not  to  test,  then  it  becomes  no  longer  a  requirement 
or  at  least  we  all  agree  that  it  is  unverified>le. " ) 

The  utilization,  assignment  and  availability  of 
RESOURCES  is  important  to  testing  and  they  are  ALLOCATED^TO 
CVPs.  This  often  determines  whether  one  can  even  perform  a 
compliance  test,  or  if  the  cost'-benefit  analysis  of 
performing  it  justifies  it.  CVPs  need  resources  so  that 
quality  systems  are  produced.  But,  if  CVP  resources 
decrease,  resources  for  design  may  increase.  There  is  a 
tradeoff  between  the  resources  allocated  to  design  and  CVPs 
that  must  be  made  in  order  to  optimize  utilization  to  attain 
the  best  system  possible. 
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2 .  Standards/Proc«dur«s/N«thods 

STANDARDS,  military  or  otherwise,  affect  testing 
procedures  in  that  they  provide  the  BASIS  for  CVPs  and 
determine  which  CVPs  are  required  and  how  they  are  to  be 
performed.  Often,  REQUIREMENTS  are  written  so  that  they 
COMPLT-WITH  STANDARDS.  It  is  important  that  the  CVPs  for  a 
requirement  use  the  same  interpretation  of  the  standards  as 
were  used  while  developing  requirements.  ("There  is  a  lack 
of  a  way  to  firmly  assure  that  the  tests  that  you  are 
generating  really  reflect  the  same  thing  as  the  standard.") 
("So  if  something  meets  the  test  it  may  not  meet  the 
standard  and  vice  versa.") 

3.  Completeness  and  Accuracy 

The  CVPs,  when  performed,  produce  test  results  that 
either  VERIFY  how  the  COMPONENTS  are  functioning  or 
IDENTIFIES  deficiencies  {CHANGES)  that  need  to  be  resolved. 
COMPONENTS  SATISFY  REQUIREMENTS  and  the  results  of  CVPs 
VERIFY  that  components  satisfy  them.  This  whole  model  is 
used  to  certify  completeness  and  correctness  of  the  system 
and  identify  changes  that  may  be  necessary  to  meet  the 
objectives.  ("As  I  change  my  design,  my  design  continues  to 
support  my  objectives.") 
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ZV.  FOCUS  GROUP  ISSUES 


This  chapter  examines  the  results  from  the  analysis  of 
data  collected  by  focus  group  research.  While  the  results 
of  research  provide  a  framework  for  a  model  of  traceability, 
many  issues  remain.  This  discussion  centers  around  those 
issues  that  need  to  be  addressed  while  implementing  a 
comprehensive  traceability  scheme. 

A.  CUSTOMER  IWVOLVEMEIIT  IR  SYSTEM  DEVELOPMENT 

The  customer  is  an  invaluable  source  of  information  in 
the  system  design  process  and  should  be  included  as  an 
integral  member  of  the  development  team.  This  is  because 
they  are  the  final  authority  on  completeness,  accuracy,  and 
quality.  Therefore,  customer  involvement  is  key  in 
developing  requirements  specifications  which  clearly 
describe  their  needs.  In  the  development  of  many  systems, 
the  customers  present  their  needs  and  intent,  in  the  form  of 
requirements,  to  the  designer.  The  designer  then  develops  a 
product  which  all  too  often  must  go  through  several  reworks 
before  it  is  accepted  by  the  customer.  This  occurs  because 
customer  feedback  is  limited  in  the  various  walkthroughs  and 
reviews  of  the  development  process. 

In  addition  to  reviews,  the  customer  is  also  important 
when  modeling  is  used,  because  ("the  customer  and  the 
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contractor  have  to  agree  on  what  the  model  will  tell  us").^ 
Some  organizations  have  incorporated  the  customer  into  every 
aspect  of  the  development  process  with  much  success. 
("They've  (the  customers)  been  there  as  the  requirements  are 
written/  they've  given  their  interpretations,  they've  put 
them  in  the  context  of  the  operational  environment.") 

To  make  the  most  from  including  the  customer  in  the 
process,  traceability  can  capture  the  requirements  rationale 
(the  why)  of  the  customers  requirements  at  the  inception  of 
the  project.  Furthermore,  an  effective  traceedsility  scheme 
will  also  include  the  identification  of  critical 
requirements.  This  will  make  even  the  limited  opportunities 
for  feedback  more  effective  by  allowing  the  customer  to 
concentrate  on  those  critical  success  factors  that  need  to 
be  looked  at.  Traceability  will  promote  customer  relations 
by  providing  important  information  to  the  customer  in  a 
timely,  organized  fashion.  This  can  assist  the  customer  in 
conducting  tradeoffs  and  cost  benefit  analysis  when  trying 
to  assess  the  impact  of  changes. 

B.  TALENTED  PEOPLE  NEEDED  ON  PROJECTS 

One  of  the  key  elements  to  success  in  any  project  are 

the  people  who  work  on  it.  Not  only  is  there  a  need  for 

people  who  are  highly  skilled  and  able  to  understand  the 

^  This  is  a  direct  quote  from  a  subject  participating  in  a  focus  group. 
Henceforth,  all  quotes  from  a  subject  will  be  enclosed  in  parentheses 
and  quotation  marks,  but  no  specific  reference  will  be  made. 
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complexity  of  the  project  but  there  is  also  the  need  for 
personnel  who  will  stay  with  a  project  over  time.  The 
quality  of  trace2d>ility  information  in  a  system  is  dependent 
on  the  quality  of  the  people  producing  it. 

Systems  have  become  so  vast  in  size  and  scope  that  they 
can  no  longer  be  designed  or  managed  by  one  entity.  As  a 
result,  systems  are  divided  into  independent  components  and 
developed  separately.  To  ensure  that  these  components  do 
not  develop  too  independently  of  each  other  it  is  edssolutely 
essential  that  the  people  involved  with  the  system  be 
knowledgeable  of  their  component,  other  components,  and  the 
larger,  parent  system  which  they  compose. 

Traceability  serves  as  an  excellent  means  of  augmenting 
the  skills  and  knowledge  of  the  people  associated  with  a 
project.  It  captures  what  is  happening  in  a  process  and 
serves  to  compile  the  history  of  the  project.  Some 
important  aspects  of  the  expertise  of  project  teams  can  be 
captured  by  traceability  information  such  as  Design 
Rationale.  On  the  other  hand,  there  are  limitations  to  how 
much  and  in  what  detail  this  information  can  be  captured  for 
traceability  cannot  capture  what  goes  on  in  the  mind  of  a 
designer.  It  can,  however,  capture  decisions  and 
assumptions  as  well  as  provide  a  link  to  the  identity  of  the 
person  who  made  them. 
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In  addition  to  providing  linkages,  traceability  can  also 
be  used  as  a  mechanism  to  facilitate  information  exchange 
among  project  participants.  Establishing  linkages  as  well 
as  capturing  information  enable  stakeholders  timely  access 
to  critical  information  and  therefore  speeds  up  the  decision 
making  process. 

C.  STAKEHOLDERS  HAVE  DIFFERENT  INFORMATION  NEEDS 

Every  requirement  in  a  system  originates  from  some 
stakeholder  and  each  of  these  stakeholders  have  varying 
needs  and  desires  from  traceability.  One  of  the  desiredsle 
features  of  traceability  is  its  ability  to  facilitate 
information  sharing  among  stakeholders.  Throughout  the 
hierarchy  of  the  organization  each  stakeholder  has 
information  needs  that  are  unique  to  their  level  of 
responsibility.  ("On  the  top  level  you  think  about 
completeness  and  correctness  and  on  the  bottom  level  you 
think  about  resource  utilization.”)  Some  of  these 
information  needs  include,  sources,  assumptions;  in  short, 
whose  need  is  being  met  and  why. 

As  well  as  identifying  their  information  needs, 
stakeholders  should  also  be  identified  by  the  requirements 
they  are  associated  with.  This  allows  changes  to  be 
evaluated  by  the  concerned  stakeholders.  Furthermore, 
identifying  stakeholders  will  enable  designers  to  determine 
the  validity  of  a  requirement  if  its  "owner"  changes. 
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Traceability  should,  at  a  minimum,  be  able  to  capture 
why  a  requirement  exists,  who  made  that  decision,  what 
additional  requirements  are  related  to  that  requirement,  and 
which  stakeholders  and  system  components  are  affected  by  the 
requirement.  The  level  of  granularity  of  information 
captured  by  traceediility  needs  to  be  such  that  each 
stakeholder  has  full  access  to  the  information  they  require. 

O.  PROBLEMS  WITH  LANOUAQE  ZHTERPRETATIOH . 

There  needs  to  be  a  formal  language  which  stakeholders 
can  use  to  communicate  with  each  other.  This  is  because 
("the  first  requirements  design  review  between  the 
government  and  the  contractor  is  to  understand  what  the 
requirements  are" ) .  System  designers  are  constantly  faced 
with  the  task  of  accurately  translating  the  customers' 
objectives  and  needs  into  system  requirements.  ("Part  of 
the  problem  is  to  write  a  functional  specification  and  to 
ensure  that  when  the  contractor  implements  it  he  builds  a 
system  that  meets  the  functional  specification.") 

Problems  like  these  stem  from  the  difficulty  involved 
with  translating  English  text  in  such  a  way  as  to  capture 
the  intent  of  the  customer.  Because  the  human  mind  is  able 
to  reason  and  judge,  interpretation  of  English  text  may  be 
solely  individual.  ("The  problem  with  traceability  here,  is 
there  is  no  way  to  map  unambiguously  from  English 
statements,  which  is  the  way  standards  are  typically 
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written,  to  any  other  language.**)  By  having  no  standard 
method  for  translating  text  into  uneunbiguous  requirements, 
it  becomes  difficult  for  the  designers  to  clearly  interpret 
the  customers  needs  and  expectations. 

To  assist  in  translating  requirements,  traceability 
should  be  able  to  relate  the  textual  description  of  a 
requirement,  by  the  customer,  to  the  actual  system 
requirement,  developed  by  the  designer,  and  to  subsequent 
derived  requirements  throughout  the  system  lifecycle.  For 
traceability  to  be  fully  functional,  there  must  be  a 
consistent  protocol  for  capturing  information  from  English 
language  text.  Then  it  must  be  clear  that  the  language  be 
used  consistently  throughout  the  system  design,  for  example, 
so  that  tests  and  standards  say  the  same  thing. 

As  one  means  of  translating  requirements,  traceability 
tools  use  a  variety  of  methods,  such  as  identifying  key 
words,  for  capturing  information  contained  in  English  text. 
However,  these  tools  are  subject  to  unique  language 
interpretations  which  affect  the  type  and  intent  of  the  data 
and  information  they  capture. 

E.  RESOURCE  COHSTRAIHTS 

Always  an  issue  is  the  allocation  and  budgeting  of 
resources  and  their  impact  on  the  overall  system.  Time, 
funding,  and  available  manpower  have  a  great  impact  on  any 
project.  ("It  takes  time  to  document  information  and  to 
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actually  sit  down  and  document  all  that  information  takes  a 
great  deal  of  time.")  As  a  non-functional  requirement « 
traceeUsility  tends  to  slip  to  the  end  of  the  project  life- 
cycle  and  is  one  of  the  first  things  to  be  eliminated  or 
scaled  down  when  a  funding  crunch  comes  along.  Because, 

("if  nobody  pays  you  to  document  and  trace  then  you  don't  do 
it"). 

As  a  compromise,  in  lieu  of  elimination,  traceability  is 
often  poorly  conducted  and  this  is  attributed  to  a  lack  of 
available  time,  money,  and  personnel.  As  a  result,  what 
information  is  captured  may  prove  to  be  no  longer  timely  or 
adequate.  This  has  a  negative  impact  because  timely  and 
accurate  information  are  crucial  to  the  decision  making 
process. 

Cutting  traceability  in  response  to  resource  constraints 
may  prove  to  be  a  poor  choice.  When  you  lose  traceability 
you  also  lose  some  management  decision  aids,  such  as  the 
ability  to  perform  impact  analysis.  Traceability  provides 
the  auditing  framework  necessary  for  monitoring  resource 
allocation  and  use.  Therefore,  it  can  be  of  benefit  during 
resource  cutbacks  by  providing  a  means  of  identifying  those 
things  that  need  to  be  cut  while  preserving  those  identified 
as  critical  success  factors.  This  information  will  enable 
stakeholders  to  carefully  weigh  alternatives  as  they 
implement  budget  cuts  and  reallocate  resources. 
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P.  NISSIOM  CRITICALITY 

("Today  the  requirements  are  evolving  on  almost  a  daily 
basis  because  the  threat  is  evolving.")  As  a  result, 
developing  systems  need  to  be  dynamic  and  responsive  in 
order  to  comply  with  constantly  chemging  threat,  missions, 
and  technologies.  To  keep  pace  with  today's  volatile 
climate,  there  needs  to  be  prioritization  of  requirements. 
The  key  to  prioritizing  is  the  identification  of  mission 
critical  requirements.  These  are  the  requirements  that  are 
essential  to  the  project  and  cannot  be  eliminated.  Such 
requirements  are  found  throughout  the  system  hierarchy  and 
have  linkages  which  extend  across  all  levels  of  the  system. 
Consequently,  the  identification  of  and  relationships 
between  mission  critical  requirements  needs  to  be  captured 
in  order  for  the  effects  of  changes  and  cutbacks  to  be 
accurately  assessed  by  stakeholders  through  cost  benefit 
analysis. 

In  today's  world  change  is  no  longer  trivial  and  can 
quickly  alter  the  basic  nature  of  a  system.  Complete 
traceability  will  help  to  manage  the  evolution  by  ened^ling 
designers  to  quickly  assess  the  impact  of  changing 
requirements  throughout  the  system.  To  support  a  dynamic 
system,  traceability  must  provide  a  means  for  capturing  the 
source  and  rationale  behind  changes. 

TraceeUsility  allows  system  engineers  to  identify  and 
prioritize  mission  critical  requirements  and  trace  their 
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linkages  throughout  the  system  lifecycle.  This  enables 
quick  assessments  of  the  impact  of  change  on  mission 
critical  requirements.  Complete  traceability  that 
identifies  critical  requirements  enables  stakeholders  to 
salvage  what  they  need  from  a  rapidly  changing  system  with 
minimal  loss. 

O.  DERIVED  REQUIREMEHTS 

System  designers  need  a  method  to  identify  both  derived 
requirements  and  their  subsequent  linkages  throughout  the 
system  hierarchy.  ("They  (requirements)  are  refined,  and 
become  more  specific  in  detail  and  in  fact  are  more 
demanding  than  the  original  requirement  might  have  been" ) . 
What  is  unique  about  derived  requirements  is  their  origin, 
they  are  not  found  in  the  original  specifications.  Derived 
requirements  tend  to  evolve  in  response  to  design 
constraints  and  implicit  assumptions  made  as  part  of  the 
design  solution.  Because  they  are  based  on  interpretation, 
derived  requirements  tend  to  be  dyneunic  and  should  therefore 
be  closely  monitored. 

Traceediility  enables  system  designers  to  identify  and 
capture  the  source  and  rationale  contributing  to  a  derived 
requirement.  This  information  is  important  because  derived 
requirements  are  usually  not  explicitly  specified  by  the 
customer  and  therefore,  ("those  are  the  ones  we  can  revisit 
and  change"). 
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H.  CONPATIBILZTX  BETNBEII  TOOLS 

The  use  of  tools  to  conduct  traceability  is  becoming 
more  popular  with  contractors  and  customers  alike. 
Traceability  tools  are  a  big  investment  for  organizations. 
And  many  organizations  spend  large  amounts  of  time  and  money 
developing  and  implementing  traceed>ility  tools  to  better 
serve  the  needs  of  their  customers.  The  problem  arises  when 
customers  and  contractors  rely  on  different  tools  to  conduct 
traceeJdility.  Contractors  feel  the  crunch  because  they  deal 
with  ("a  wide  variety  of  customers  and  those  customers  want 
outputs  in  their  set  of  tools").  Hence  there  is  a  need  for 
compatibility  among  the  available  traceability  tools. 

To  ensure  compatibility,  traceability  tools  should  focus 
on  capturing  information,  in  a  similar  format,  to  a  common 
database.  Differences  in  tools  should  not  be  in  the  type  of 
data,  but  rather  the  manner  in  which  data  is  manipulated  and 
presented.  Stakeholders  want  a  versatile  tool  because,  ("if 
you  have  a  really  good,  robust  database,  or  engineering  tool 
and  you  can  get  data  out,  hard  copy  in  different  formats 
you're  well  ahead.  We  want  a  requirement  stored  in  one 
place  to  go  out  in  as  many  docxunents  as  it  needs  to" ) . 

I.  CAPTURE  OP  IHFORMATIOH 

How  to  capture  information  as  the  system  development 
process  evolves  is  a  great  challenge  facing  systems 
designers.  Traceability  information  must  be  captured  by  the 
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people  doing  the  design  rather  than  someone  else  whose  job 
is  to  create  the  documentation.  The  best  way  is  to  capture 
information  as  part  of  the  development  process,  for  then, 
information  is  captured  as  it  is  created.  The  problem  here 
is,  it's  very  difficult  to  get  the  system  engineers  to  ("sit 
down  long  enough  to  really  think  about  what  it  is  they  want 
because  a  lot  of  cases  they'll  walk  into  the  simulator  and 
think  of  something  new  while  they're  flying").  Keeping  in 
mind  that  information  is  only  as  good  as  the  people  creating 
it  want  to  make  it,  an  incentive  mechanism  should  be  built 
into  systems.  Designers  must  feel  that  complete 
traceability  is  necessary  because  of  either  some  type  of 
reward  or  penalty. 

To  capture  the  information  created  by  the  designer 
requires  a  continual  process.  This  process  should 
facilitate  the  capture  of  information  on-line,  from  the 
source,  functionally  organizing  it,  reviewing  and  sharing 
the  information,  and  verifying  that  the  stakeholders 
information  needs  have  been  met.  Using  traceability  enables 
you  to  look  at  all  aspects  of  a  decision  and  exeunine  all  the 
areas  affected  by  it. 

J.  PUHDING  PROFILE  OF  PROJECTS 

In  many  projects  today,  especially  in  DoD,  the  funding 
provided  for  system  development  is  apportioned  in  phases. 

As  part  of  this  funding  profile,  initial  funds  for 
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requirements  management  and  design  tend  to  be  rather  limited 
with  the  bulk  of  the  funds  allocated  to  latter  phases  of 
development.  This  is  difficult  for  the  developer  who  must 
define  and  identify  requirements  as  well  as  establish  a 
scheme  for  traceability  information  capture  in  the  early 
stages  of  the  system  lifecycle. 

A  traceability  scheme,  with  its  high  startup  costs, 
becomes  a  problem  when  only  limited  funding  is  available  at 
the  start  of  a  project.  Traceability,  to  be  effective,  must 
be  comprehensive  in  the  early  stages  of  a  project.  Project 
sponsors  should  realize  that  without  adequate  funds  to 
support  it,  a  complete  traceability  scheme  cannot  be 
implemented  at  the  start  of  the  project. 

K.  LIVING  TRACEABILITY  DOCUMENT 

Traceability  information  is  not  something  that  is 
captured  at  one  point  in  the  system  lifecycle  and  stays 
stable.  On  the  contrary,  a  good  traceedsility  scheme  is  one 
that  is  constantly  updated  throughout  the  lifecycle  of  the 
system.  Information  needs  to  be  captured  as  early  as 
possible  for  use  later  in  the  project. 

To  capture  information,  many  organizations  use  daily 
notebooks  or  unit  folders  which  serve  as  a  repository  for 
all  information  concerning  a  project.  These  are  maintained 
by  the  individual  or  manager  and  contain  dociunentation 
reflecting  decisions  and  changes  as  they  occur  within  the 
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system  development  process.  Such  information  should  be 
captured  and  maintained  in  a  more  formal  traceeibility 
environment . 

L.  EMBEDDED  AS8UKPTXb*;8 

AS  designers  refine  requirements  in  the  system 
development  process  there  are  assumptions  which  they  make 
unknowingly.  These  assvimptions  are  not  explicit,  they  may 
be  obvious  to  the  person  developing  them  but  not  to  others. 

( "Even  if  you  write  it  down  you  might  make  some  unstated 
assxmptions  that  over  time  might  change.  And  the  other 
person  comes  back  and  looks  for  that  information,  they  could 
be  working  on  a  totally  new  set  cf  assumptions.")  Even  if 
you  have  a  traceeOsility  model,  you  may  not  capture  all  the 
required  information  as  some  stakeholders  may  not  even 
realize  that  some  information  obvious  to  them  may  not  be 
obvious  to  others. 

To  counter  this  problem  of  capturing  assumptions,  there 
needs  to  exist  a  detailed  model  of  what  information  needs  to 
be  captured.  The  more  detailed  the  traceability  model,  the 
better  chance  of  capturing  the  true  intent  and  assumptions 
behind  a  decision. 

N.  ACCOUNTABILITY 

Some  decisions  and  requirements  have  little  technical  or 
functional  justification.  Because  they  are  of  this  type,  it 
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is  important  for  system  designers  to  capture  the  information 
contained  in  their  rationale  and  assmnptions .  Designers 
need  to  identify  the  stakeholder  responsible  for  the 
requirement,  because  sometimes  you  can  not  explicitly 
capture  all  the  information.  This  is  because;  for  example, 
the  need  for  the  requirement  may  go  away  if  the  stakeholder 
leaves  the  project. 

n.  ACCOUNTABILITY  VERSUS  PERFORMANCE  APPRAISAL 

Traceability  helps  to  determine  who  is  accountable  for 
requirements  by  idev^tifying  stakeholders  and  the  rationale 
they  used  for  developing  requirements.  (**1  think  you  need 
to  be  sensitive  to  it  (traceability)  when  you  conceptualize 
your  requirements  so  you  know  why  they  are  requirements  and 
so  that  you  know  as  you  are  writing  them  that  you  are  going 
to  be  accountable  down  the  road  to  see  that  those  can 
actually  be  carried  out.")  As  a  word  of  caution  though, 
traceability  should  not  be  used  for  performance  evaluation. 
Rather  it  should  be  used  as  a  way  to  understand  and  correct 
mistakes.  To  prevent  the  fear  of  being  held  culpedsle,  a 
good  idea  is  to  evaluate  decisions  and  make  them  as  a  group. 

O .  LEGAL/ PROPRIETARY 

Certain  design  procedures  may  contain  information  that 
the  developer  may  feel  is  confidential/proprietary.  The 
question  then  arises,  if  the  designer  uses  traceability  to 
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capture  their  design  rationale  on  a  project,  are  they 
required  to  provide  that  information  to  the  customer  who 
funded  the  project? 

Traceability  provides  the  mechanism  of  ensuring  that  the 
customer  is  getting  what  they  have  paid  for.  However,  the 
idea  of  full  disclosure  of  information  by  the  designer  is 
one  that  many  feel  is  on  the  verge  of  revealing  trade 
secrets.  The  requirement  to  divulge  traceability 
information  is  something  that  should  be  included  in  the 
contract  negotiation  process  and  issues  of  proprietary 
information  must  be  sorted  out. 
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V.  CONCLUSKM  AMP  RECOMMEMOATIOMS 


A.  MOPEL 

Department  of  Defense  Standard  2167A  requires  that 
requirements  traceability  be  conducted  during  systems 
development.  However,  this  standard  (and  other  standards 
that  require  traceability)  offer  no  comprehensive  model  for 
use  by  developers  that  states  what  information  should  be 
captured  as  a  part  of  a  traceability  scheme.  Our  research 
developed  a  model  of  traceability  based  on  the  information 
needs  of  various  stakeholders  in  systems  development.  This 
model,  as  described  in  Chapter  III,  provides  a  basic 
framework  for  use  in  conducting  traceability. 

B.  IMPLEMEMTATIOM 

To  successfully  implement  requirements  traceability  in 
systems  development,  it  needs  to  be  integrated  into  the 
systems  development  process.  A  systems  development 
methodology  must  recognize  that  the  capture  and  use  of 
requirements  traceability  information  must  be  done  as  the 
system  is  created  and  maintained.  Much  of  the  traceability 
information  can  be  automatically  captured  if  properly 
supported  by  tools.  CASE  tools  that  automatically  capture 
as  the  system  evolves  are  essential. 
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C.  DEVELOPMENT  OP  MODEL  COMPONENTS 

While  the  proposed  model  provides  a  framework  for 
conducting  requirements  traceability,  there  are  component 
parts  which  require  further  refinement.  For  instance,  a 
comprehensive  design  rationale  model,  such  as  REMAP,  with 
support  mechanisms  may  be  used  to  include  some  of  our  model 
primitives.  Depending  on  the  project  needs,  components  that 
concentrate  on  specific  issues  such  as  reliability  and/or 
change  management  may  be  developed.  By  elaborating  on  each 
of  these  processes,  traceability  will  provide  more  accurate 
and  useful  information  to  stakeholders. 

D.  DEVELOPMENT  OP  MECHANISMS 

Combined  with  our  model,  which  outlines  what  information 
to  capture,  there  needs  to  be  mechanisms  which  specify  how 
information  can  be  combined  and  used  by  stakeholders.  An 
example  would  be  a  mechanism  which  identifies  how  critical 
success  factors  can  be  tracked  through  various  system 
components  to  support  cost  benefit  analysis.  Mechanisms 
that  facilitate  reasoning  with  traceability  information 
should  be  developed  to  support  various  stakeholder  needs. 

E.  LIVING  (EVOLVING)  DOCUMENT 

Current  practices  of  producing  static  traceability 
documents  that  become  obsolete  almost  as  they  are  created  is 
wasteful.  As  a  system  develops  through  its  lifecycle,  the 
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traceability  documentation  should  constantly  evolve  to 
reflect  the  current  status  of  the  system,  without  an 
existing  requirements  traceability  scheme  during  the  entire 
lifecycle  of  the  system,  certain  key  pieces  of  information 
may  not  be  captured.  This  results  in  a  breakdown  of  the 
traceed>ility  scheme  and  the  information  available  becomes 
useless. 

r.  LIPECXCLE  COST  BENEFIT 

While  required,  traceed)ility  is  all  to  often  not 
included  into  the  funding  profile  of  a  project,  and  in  those 
where  funding  is  available,  it  is  rarely  sufficient. 
Furthermore,  funds  for  projects  are  allocated  by  phase  with 
the  initial  phases  receiving  the  smallest  allocation. 
Requirements  traceability  can  reduce  system  costs  by 
enhancing  decision  making  and  streamlining  the  development 
process.  Therefore,  requirements  traceability  should  be 
included  in  a  project's  funding  profile  by  looking  at  the 
benefits  it  provides  throughout  the  entire  lifecycle. 

O.  SUGGESTIONS  FOR  FUTURE  RESEARCH 

Follow-on  research  to  this  thesis  should  include: 

•  Validation  of  our  Requirements  Traceability  Model  using 
focus  groups  consisting  of  stakeholders  that  are 
familiar  with  traceability. 

•  Personal  interviews  and  additional  focus  groups  to 
refine  and  expand  component  processes  of  our 
Requirements  Traceability  Model. 
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•  Exploration  of  tools  and  techniques  to  resolve  Issues 
raised  in  the  development  of  a  model  for  requirements 
traceability. 
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